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Figure 4-125; Ready Circuit Functional Test (Part A) 
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Keystroke Functional Test (Part B) 
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Figure 4-126: Ready Circuit Functional Test (Part B) 
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Keystroke Functional Test (Part C) 
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Figure 4-127: Ready Circuit Functional Test (Part C) 
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Keystroke Functional Test (Part D) 
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Figure 4-128: Ready Circuit Functional Test (Part D) 
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Programmed Functional Test 



4.14.6. 



The tstjeady program is the programmed functional test for the 
Ready Circuit functional block. This program checks the Ready 
circuit using the gfi test command. If the gfi test command fails, 
the abortjest program is executed and GFI troubleshooting 
begins. (See the Bus Buffer functional block for a discussion of 
the abortjest program). 

The gfi test command executes a number of stimulus programs. 
The ready _1 9 ready _2, ready _3, and ready Jf stimulus programs 
overdrive nodes in order to break the feedback loop in the Ready 
circuit. These programs will ask the operator to use a second 
clip on a second component so that the circuit can be overdriven. 

program tst_ready 



t t t t t i t i i i i i t i\ t i t t i i i i j i t t t t i i i j n it t t t t t t t t t t i i i i i t m t J J i t i i i t i t t t t t t 
FUNCTIONAL TEST of the READY functional block. 

This program tests the READY functional block of the Demo/Trainer. 
The gfi test command and I/O module are used to perform the test. The 
ready test involves overdriving components to break the feedback loop 
in the ready partition. Two I/O module clips are reguired; one for 
measurement and one for stimulus (overdriving) „ 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



If gfi has an accusation 
display the accusation else 
create a gfi hint for the 
ref-pin and terminate the test 
program (GFI begins trouble- 



shooting) . 

i i i i t t t t t t t t t t t t t t t t t i t t t i t i t i t i i i i t i i t t i i i i i i t i t i i i t t t t 



t t t t t t t t t t t t t t t 



if (gfi status "Ul-4") = "untested" then 
print "\nl\nlTESTING READY CIRCUIT" 

podsetup 'enable "-ready 1 "off" 
podsetup 'report forcing' "off" 

if (gfi status "Ul-4") = "untested" then gfi test "Ul-4" 

if (gfi status "Ul-4") = "bad" or (gfi status "Ul-2") = "bad" or 

(gfi status "Ul-3") - "bad" then 
abort_test ("Ul-4") 
else 

print "READY CIRCUIT PASSES" 
end if 
end if 
end program 
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Stimulus Programs and Responses 4.1 4.7. 

Figure 4-129 is the stimulus program planning diagram for the 
Ready Circuit functional block. The ready 1, ready J2, 
ready _3, and ready _4 stimulus programs use one clip for 
measurement and a second clip to overdrive the Ready circuit in 
order to break the feedback loop in this circuit, ready _5 and 
ready _6 provide stimulus to measure the operation of the I/O 
ready generator, U17. These two stimulus programs count how 
many 8 Mhz clocks occur during the wait state generated by 
U17. 

The steps to break the Ready feedback loop to diagnose a fault 
are shown below: 

1. Overdrive inputs U4-4 and U4-5. Then measure 
outputs U4-6 and Ul-4. The 82284 chip (Ul) 
synchronizes the Ready output (U4-6) to the 
microprocessor read/write cycles. This requires the 
ready _1 stimulus program to output the level, allow 
enough time for the signal to get synchronized, then 
check the level at the output Ul-4. 

2. Finish breaking the Ready signal feedback loop by 
overdriving inputs U4-12 and U4-13, then measure 
the outputs U4-11, U5-3, and U4-6. In order to 
measure U5-3 and U4-6, the other inputs U5-1 and 
U4-5 must be held high so the signals will flow 
through the AND gates. The ready _4 stimulus 
program performs this step. 

3. Hold the node with output source U4-1 1 high. This 
allows signals from U6 to flow through U5-3 to U4- 
6. At the same time, holding U4-11 high causes 
output U17-11 to stabilize at a high state, allowing 
signals from U56 to ripple through U5-6 to U4-6. 
Now use the pod to exercise the Ready Circuit inputs 
that are driven by the Address Decode functional 
block. The ready _2 stimulus program performs this 
sequence for all components that can be forced to use 
zero wait states. It does this by disabling U17 (all 
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components except RAM and Video RAM). Since 
the pod has turned -READY ENABLE OFF, the pod 
generates a sync pulse with zero wait states. 
Because the RAM and Video RAM return wait states, 
taking signature measurements on RAM and Video 
RAM will turn out to be unstable. To solve this 
problem, ready J, accesses all components except 
RAM and Video RAM. Then the ready Ji stimulus 
program performs a similar operation, but exercises 
only RAM and Video RAM. ready 3 responses are 
characterized by asynchronous level history and 
transition counts to allow the RAM and Video RAM 
wait state signals to be measured. 

Measure the I/O component wait state generator, 
U17. The Clear input at U17-9 is toggled low. At 
the same time a measurement using external Clock 
(and Start) is made. The External Clock line is 
connected to the 8 MHz clock CLK and the Start line 
is connected to the node which includes U17-9. A 
Stop Count is set and transition counts and level 
history are measured. The ready 6 stimulus 
program uses a Stop Count of four clocks and the 
response is expected to be low level history and zero 
transitions, indicating that the wait state output was 
low for at least four clocks. The ready _5 stimulus 
program uses a Stop Count of six clocks. In this 
case, a response of high and low level history is 
expected, and a transition count of 1 is expected. 
These results indicate that the wait state finished 
within six clock cycles. 



Advice for Making GFI Work in the Presence of Ready Faults 

When a Ready fault exists, a forcing-line fault condition will be 
generated. However, the pod must ignore the Ready 
forcing-line fault condition so that the stimulus program will 
execute completely. Otherwise, a fault condition would be 
generated and GFI would terminate. To turn this report off, a 
SETUP REPORT FORCING -READY OFF command can be 
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performed. When this is done, the pod will continue to respond 
to the Ready signal, but will not generate a fault message. If the 
Ready signal is stuck high, the pod will cause the 9100A/9105A 
to generate a pod timeout fault condition. To cure this, a SETUP 
ENABLE -READY OFF command is performed. At this point, 
GFI will work properly and Ready problems can be isolated to 
the failing component or node. 

More generally, GFI works best if every stimulus program turns 
all reporting conditions off. In addition, those stimulus 
programs that create activity in the kernel area, may need to turn 
off Enable Ready. All Demo/Trainer UUT stimulus programs 
related to the address bus, data bus, control signals, address 
decoding, interrupts, and ready circuitry turn the Ready Enable 
off at the beginning of the stimulus program and the turn Ready 
Enable back on at the end of the program. 

One more note: the 80286 microprocessor uses a separate bus 
controller that has no feedback lines to the microprocessor. 
When the pod disables the Ready input and performs zero wait 
state operations regardless of the Ready input, the bus controller 
can get out of synchronization from the pod and may get 
confused. When this happens, an enabled Jinejimeout fault 
condition is generated. The solution is to provide a handler for 
that fault condition in each stimulus program that enables and 
disables Ready. The handler for the fault condition should call a 
program which performs a recovery procedure. The recovery 
procedure depends on the UUT. Usually, forcing the Ready 
line active or performing a Reset will recover synchronization. 
Or, by disabling Ready and then performing a read or write in 
memory space followed by enabling Ready may recover 
synchronization of the 80286 pod and the bus controller. Most 
other microprocessors do not have this problem. 
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Stimulus Program Planning 



PROGRAM: READY-1 



OVERDRIVES U4-6 TO CHECK THE SYNCHRONIZED 
READY OUTPUT 



MEASUREMENT AT: 



U1-4 
U4-6 



PROGRAM: READY_4 



BREAKS THE READY FEEDBACK LOOP BY 
OVERDRIVING THE NODE AT U4-1 1 



MEASUREMENT AT: 



U4-11 
U5-3 



PROGRAM: READY- 2 



OVERDRIVES THE NODE AT U4-1 1 AND ALSO 
EXERCISES THE READY RETURN LINES (EXCEPT 
VRAM AND VRAMRDY) 



MEASUREMENT AT: 

U4-6,8 
U5-3.6 

U55-8 



PROGRAM: READY S 



OVERDRIVES THE INPUT TO THE I/O WAIT STATE 
GENERATOR AND CHECKS THAT THE OUTPUT 
U17-11 TRANSITIONS FROM LOW TO HIGH WITHIN 7 
CLOCKS OF THE INPUT U17-9 



MEASUREMENT AT; 

U17-11 



PROGRAM: READY_3 



OVERDRIVES THE NODE AT U4-11 AND EXERCISES 
THE READY RETURN LINES VRAM AND VRAMRDY 



MEASUREMENT AT: 

U4-6 

U5-3 
U6-3 



PROGRAM: READY_6 



OVERDRIVES THE INTUT TO THE I/O WAIT STATE 
GENERATOR AND CHECKS THAT THE OUTPUT 
U1 7-11 TRANSITIONS FROM HPGH TO LOW WITHIN 4 
CLOCKS AFTER Ul 7-9 GOES HIGH 




• 
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Figure 4-129: Ready Circuit Stimulus Program Planning 
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program ready_l 



I I I ! M ! I 1 I I I I I I 1 I ! I f 1 I I I I I 1 I -t I I I I I 1 ! t I I I I I 1 I I I I I I ! I I I I I 1 I I t I I I I I I I 1 I ! M 



STIMULUS PROGRAM overdrives U4 in ready circuit. 
Characterizes U4-6 and Ul-4. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover {) program is executed to 
resynchronize the bus controller and the pod. 



I 



TEST PROGRAMS CALLED: 
recover () 



GRAPHICS PROGRAMS CALLED: 
(none) 



Global Variables Modified: 
recover times 



Local Variables Modified: 
measure_dev 
stimulus_dev 
t t r t 1 1 t i t t t t i t t i i t i i i i t 1 1 1 1 t t t t 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control- 
ler. The recover program ! 
resynchronizes the pod and the 
bus controller. 



Reset to Zero 



Measurement device 

Stimulus device (overdrives) 



t t t t t t t t i i t i i i i i i i 



Main Declarations 
t i i i i i i t t t t t t t t i i i 



1 1 t t t t t ! 1 1 1 



i t t t 1 1 1 1 t t t i i 1 1 1 i i 



i t 1 1 1 1 i 



t t t t i t t t 



declare global numeric recover_times 



(continued on the next page) 



Figure 4-130: Stimulus Program (ready_1) 
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! ! ! ! ! t t t t t j t j t i i t t i i I I i t t t t t i i i i ; ; j j i t i i i t t j t t t j j t ! t '! M !!!!!!!!!!! !! !!! ! 
! FAULT HANDLERS: ! 

I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!'!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

handle pod_timeout_enabled_line 

recover () 
end handle 
handle pod_timeout_recovered 

recover () 
end handle 

handle pod_timout_no_clk 
end handle 

! ! i m t t t t t m r i j i i i i i i I i i j j | t i i i j j i t t i t i i t j i j t t i i j j j j i i i I I t i i i i i t t t t i i i i t t 
! Main part of STIMULUS PROGRAM I 

!!!!!!!!!!!!!!!! H ! t! !!!!!!! H !!!!!!! M !!!!!!!!!!!!! I! !!!!!! t !!!!!! I !! I ! ! 

recover_times » 

! Let GFI determine measurement device 

if (gfi control) = "yes" then 

measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print " (Chose Ul, U4, U14 or U15)" 

measure_ref = "" \ input measure_ref 

if measure_ref <> "U14" then 

measure_dev = clip ref measure_ref 

else 

probe ref "U14-63" \ measure_dev = "/probe" 

end if 
end if 

! Determine stimulus device 

if measure_ref = "U4" then 

stimulus_dev = measure_dev 
else 

print "\07\lB[2J\lB[201\lB[3;lf USING \lB[7mSECOND\lB[0m CLIP. 

stimulus_dev = clip ref "U4" 

print "\lB[20h" 
end if 
print "Stimulus Program READY_1" 



(continued on the next page) 
Figure 4-130: Stimulus Program (ready_1) - continued 



4-355 



Ready Circuit 



! Setup measurement device. 

podsetup 'enable -ready' "off" 
podsetup "standby function off 
podsetup 'report power' "off" 
podsetup 'report forcing' "off" 
podsetup 'report intr' "off" 
podsetup 'report address' "off" 
podsetup "report data' "off" 
podsetup "report control" "off" 
reset device measure_dev 
reset device stimulusjdev 
sync device measurejdev, mode "int" 

! Perform Stimulus 

arm device measure_dev 

writepin device "U4", pin 4, level "1", mode "latch" 

writepin device "U4", pin 5, level "1", mode "latch" 

strobeclock device measure_dev 

writepin device "U4", pin 4, level "0", mode "latch" 

writepin device "U4", pin 5, level "1", mode "latch" 

strobeclock device measure_dev 

writepin device "U4", pin 4, level "1", mode "latch" 

writepin device "U4", pin 5, level "1" 

strobeclock device measure_dev 

writepin device "U4", pin 4, level 

writepin device "U4", pin 5, level 

strobeclock device measure_dev 

writepin device "U4", pin 4, level 

writepin device "U4", pin 5, level 

strobeclock device measure_dev 
readout device measure_dev 

clearoutputs device stimulus_dev 
podsetup 'standby function on' 
podsetup 'enable ~ready' "on" 

end program 



"1", 


mode 


"latch" 


111 II 

± f 


mode 


"latch" 


"0", 


mode 


"latch" 


"1", 


mode 


"latch" 


"1" 


mode 


"latch" 



Figure 4-130: Stimulus Program (ready_1) - continued 
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STIMULUS PROGRAM NAME: READY_1 

DESCRIPTION: SIZE: 94 BYTES 



Response Data 



Node Learned Async Clk Counter Priority 

Signal Src With SIG LVL LVL Mode Counter Range Pin 

U4-6 I/O MODULE 0015 1 TRANS 

Ul-4 PROBE 0015 1 TRANS 

Ul-4 I/O MODULE 0015 1 TRANS 



Figure 4-131 : Response File (ready_1) 
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program ready_2 



t M M M t t t t t t t t t t t t M I t t t 1 t t t M M t t t t M 1 t t t t t t M t t 1 I T M I t 1 1 I I M t I t t 1 t 1 t 



STIMULUS PROGRAM overdrives U4 in ready circuit. 
Characterizes U4-6 and Ul-4. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover () program is executed to 
resynchronize the bus controller and the pod. 



TEST PROGRAMS CALLED: 
recover () 



GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover times 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control- 
ler. The recover program 
re synchronizes the pod and the! 
bus controller. 



Reset to Zero 



Local Variables Modified: 
measure_dev 
stimulus_dev 
) t i t t t t t t t I ! I I i t i i t t t 1 1 1 t t t t t t t t t 1 1 1 1 1 t t t i i m t t t ! 1 1 1 1 t t t t 1 1 t f t t t t t t i t n 



Measurement device 

Stimulus device (overdrives) 



I I I I I I ! I I t t t t t M 



Main Declarations 
i i t t t t » t t t t I 1 I 1 I I I I I I I ! I ! I I I i i t t t I I i t't t i t i t i t ! i t I I I ! ! T I I I I I I I i i t t t t i t t t 



1 1 t t i 1 1 1 t 



declare global numeric recover times 



(continued on the next page) 



Figure 4-132: Stimulus Program (ready_2) 
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I t t j j i i i i i i i i i i I I i i i j i j i i i i t t r rt t t i t t t t t i i i t j t i i i i j t t t i m j J | i i i i i t t t j i t t t 
! FAULT HANDLERS: ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

handle pod_timeout_enabled_line 

recover () 
end handle 
handle pod_timeout_recovered 

recover () 
end handle 

handle pod_timout_no_clk 
end handle 



n j n t j t i j n i I i i i j t j ! ! j j ! n j j i j j n i ! ! ! I i m ! ! I ! ! ! ! ! ! n m ! ! ! ! t ! ! ! ! ! ! ! t ! ! ! t 
! Main part of STIMULUS PROGRAM 

!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M!l!!i!!!!!!!!!!!!!!!!N!!! 

recover_times = 

! Let GFI determine measurement device 

if (gfi control) = "yes" then 

measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print " (Chose Ul, U4, U5, U6, U56 or U17) " 

measure_ref = "" \ input measurejref 

measure_dev « clip ref measure_ref 
end if 

! Determine stimulus device 

if measure_ref = "Ul" then 

print "\07\lB[2J\lB[201\lB[3;lf USING \!B[7mSECOND\lB[0m CLIP. 

stimulusjdev = clip ref "U4" 

print "UB[20h" 
else 

stimulus_dev = measure_dev 
end if 
print "Stimulus Program READY__2" 

! Setup measurement device. 

podsetup 'enable -ready' "off" 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address" "off" 

podsetup 'report data" "off" 

podsetup 'report control' "off" 

io_byte = getspace space "i/o", size "byte" 

mem word = getspace space "memory", size "word" 



(continued on the next page) 
Figure 4-132: Stimulus Program (ready_2) - continued 
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reset device measure_dev 

reset device stimulus_dev 

sync device measure_dev, mode "pod" 

sync device "/pod", mode "data" 

old_cal = getoffset device measure_dev 

setoffset device measure_dev, offset (1000000 - 56) 

if measure_ref = "U5" then 

writepin device "U5", pin 2, level "1", mode "latch" 
writepin device "U5", pin 4, level "1", mode "latch" 

else if measure_ref -= "U4" or measure_ref - "Ul" then 
writepin device "U4", pin 11, level "1", mode "latch" 

end if 

Stimulate ICs and capture response. 



arm device measure_dev 


! Start response captu 


s et space (mem_word) 




read addr $30000 


! IPOLL 


read addr $40000 


! SPARE1 


read addr $50000 


! SPARE2 


read addr $E0000 


! ROM0 


read addr $F0000 


I ROM1 


setspace (iojDyte) 




read addr 


! VIDSLT 


read addr $2000 


I I/OSLT 


read addr $4000 


r PPISLT 


readout device measure_dev 


! End response capture 



if stimulus_dev <> "/probe" then clearoutputs device stimulus_dev 
setoffset device measure_dev, offset old_cal 
podsetup 'enable -ready' "on" 



end program 



Figure 4-132: Stimulus Program (ready_2) - continued 
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STIMULUS 


PROGRAM NAME: 


READY_ 


_2 










DESCRIPTION: 










SIZE: 


143 BYTES 










arise 


Data 




















Node 


Learned 




Async 


Clk 


Counter 




Priority 


Signal Src 


With 


SIG 


LVL 


LVL 


Mode 


Counter Range 


Pin 


U4-6 


I/O MODULE 


0000 


1 




TRANS 






U4-8 


PROBE 


007E 


1 




TRANS 






U4-8 


I/O MODULE 


007E 


1 




TRANS 






U5-3 


I/O MODULE 


0086 


1 




TRANS 






U5-6 


I/O MODULE 


0078 


1 




TRANS 






U56-8 


PROBE 


0086 


1 




TRANS 






U56-8 


I/O MODULE 


0086 


1 




TRANS 






U6-8 


I/O MODULE 


0078 


1 




TRANS 







%ffl 



Figure 4-133: Response File (ready_2) 
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program ready_3 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! !!!!!! ! ! !!!!!!!!!!!!!!!!! I I I 
STIMULUS PROGRAM toggles ready circuit inputs which generate 
wait states. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover () program is executed to 
resynchronize the bus controller and the pod. 



TEST PROGRAMS CALLED: 
recover () 



GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulus dev 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control- 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 



Reset to Zero 



Measurement device 

Stimulus device (overdrives) 



! ! ! ! ! 

i i i I I 
Main 

! I ! I T 


TTTTTTTT 

!!!!!!!! 
Declarat 
!!!!!!!! 


i i i i I J u t t t t t i i i i i j r t t i I I i r t r i i i i t t t t t t t t t t j t I t i i i i ; i || ji| 

t t t t i i i i i j i i i } t t t t t t i t t t t t t t i i i t t t i i i i j i r | t t t i j i i i j mimm 
ions ! 
!!!!!!! II !!!!!!!!! II !!!!!!! I !!!!!!!!!!!!!!!!!!! !! I !!!!!!! ! 



declare global numeric recover_times 



(continued on the next page) 



Figure 4-134: Stimulus Program (ready_3) 
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I !! !!!!!!!!!!!!!!!!!!!!!!!! I !!!!!! I !!!!!!!!! I ! ! I !!!!!!!!!!!!!!!! M !!!!! ! ! 

! FAULT HANDLERS: ! 

i i i i i i i i i i i i i i i i i i t t t t t ft t n i i i i t t t it i i t j j t i t i t t j t t i i i r J m t i t i i j j t t i t t i i i 

handle pod_tiraeout_enabled_line 

recover (} 
end handle 
handle pod_timeout_recovered 

recover () 
end handle 

handle pod_timout_no_clk 
end handle 

I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! Main part of STIMULUS PROGRAM ! 

t t j j t t i t t t i t i i i i i i i j t i j i t i t t j t i I t t I I i i j i j i t i i i j | t t i j i j t t l l l I n II !!!!!!!! ! 

recover_times = 

! Let GFI determine measurement device 

if (gfi control) = "yes" then 

measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print " (Chose Ul, U4, U5 or U6) " 

measure_ref = "" \ input measure_ref 

measure_dev = clip ref measure_ref 
end if 

! Determine stimulus device 

if measure_ref = "Ul" then 

print "\07\lB[2J\lB[201\lB[3;lf USING \lB[7mSECOND\lB[0m CLIP. 

stimulus_dev = clip ref "U4" 

print "\lB[20h" 
else 

stimulus_dev = measure__dev 
end if 
print "Stimulus Program READY_3" 



(continued on the next page) 
Figure 4-134: Stimulus Program (ready_3) - continued 
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! Setup measurement device. 

podsetup 'enable -ready' "off" 

podsetup 'standby function off 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

io_byte » getspace space "i/o", size "byte" 

mem_word = getspace space "memory", size "word" 

reset device measure_dev 

reset device stimulus_dev 

sync device measure_dev, mode "pod" 

sync device "/pod", mode "data" 

old_cal = getoffset device measure__dev 

setoffset device measure_dev, offset (1000000 - 56) 

if measure_ref = "U5" then 

writepin device "U5", pin 2, level "1", mode "latch" 
writepin device "U5", pin 4, level "1", mode "latch" 

else if measure_ref = "134" or measure_ref = "Ul" then 
writepin device "U4", pin 11, level "1", mode "latch" 

end if 

! Stimulate ICs and capture response. 

arm device measure_dev ! Start response capture. 

setspace (mem_word) 

read addr ! RAM0 

read addr $10000 ! RAMI 

write addr $20000, data ! VRAM (write only) 

readout device measure_dev ! End response capture. 

clearoutputs device stimulus_dev 
setoffset device measure_dev, offset old_cal 
podsetup 'standby function on' 
podsetup 'enable --ready' "on" 

end program 



Figure 4-134: Stimulus Program (ready_3) - continued 
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STIMULUS PROGRAM NAME: READY_3 

DESCRIPTION: SIZE: 112 BYTES 

Response Data 

Async Clk Counter Priority 

:G LVL LVL Mode Counter Range Pin 

1 TRANS 3 
1 TRANS 3 
1 TRANS 3 



Nod< 




Learned 


Signal 


Src 


With 


U4-6 




I/O MODULE 


U5-3 




I/O MODULE 


U6-8 




I/O MODULE 



Q 



Figure 4-135: Response File (ready_3) 
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program ready_4 



I I I 11 !!!!!!!!!! I !!!!!!!!! II !!!!! ! I !!!!!! I ! !!!!!!!!!!!!!! M ' M * T • ' ' ' ' ' ' ' 



STIMULUS PROGRAM overdrives U4 in ready circuit. 
Characterizes U4-6 and Ul-4. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the. pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover () program is executed to 
resynchronize the bus controller and the pod. 



TEST PROGRAMS CALLED: 
recover () 



! 



GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulus dev 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control- 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 



Reset to Zero 



Measurement device 

Stimulus device (overdrives) 



i i i i i j i i i 



1 I I I t ! t 1 1 1 I I t 1 t 1 1 1 I 1 t t 1 1 1 1 I 



1 1 1 1 I t 1 t t t I I I I 



I I t t t t t t t t I t t t t t t I t t 



1 f t t t t t t t t t I I t t t t 1 t I M t I t 1 t t I 



■ t t t 1 t t M ! M t t 



Main Declarations 
t t t t t t t t t i i t i i t 1 1 1 1 ! 1 1 t t i t t I 1 1 r t t t 1 1 1 1 i t t t 1 1 1 f t t t t t 1 1 1 1 t t t t i 1 1 1 1 1 1 t i t I 



declare global numeric recover_times 



(continued on the next page) 



Figure 4-136: Stimulus Program (ready_4) 
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! M ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! I I ! ! !! !! ! ! ! ! I ! ! !! M ! ! I ! ! ! ! ! !I ! ! ! ! !! I I H ! ! ! ! I ! M ! ! !! 

FAULT HANDLERS: 
!!! I ! J ! I I ! !!!!!!!!!!!!! I M !!!!!!!!!!!!!!!! I !!!!!!! M t t i i j t f t i i I I i t n t t i 

handle pod_timeout_enabled_line 

recover () 
end handle 
handle pod_timeout_recovered 

recover () 
end handle 

handle pod_timout_no_clk 
end handle 

!!!!!!!!!!!!!!!!!! n n !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! mm ! 
! Main part of STIMULUS PROGRAM ! 

!!!!!!!!!!!!!!!!!!!!!!!! t !!!!!!!!!!! t !!!!!!! i !!!!!! !!!!!!!!!!!!!!!!!! t | m 

recover_times = 

! Let GFI determine measurement device 

if (gfi control) = "yes" then 

measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print " (Chose U4, U5 or U17)" 

measure_ref = "" \ input measure_ref 

measure_dev = clip ref measure_ref 
end if 

! Determine stimulus device 



if measure__ref = "U4" then 

print "\07\lB[2J\lB[201\lB[3;lf 
stimulus_dev = clip ref "U45" 

else if measure_ref = "U5" then 
print "\07\lB[2J\lB[201\lB[3;lf 
stimulus_dev = clip ref "U17" 

else if measure_ref = "U17" then 
print "\07\lB[2J\lB[201\lB[3;lf 
stimulus_dev = clip ref "U4" 

end if 

print "\lB[20h" 

print "Stimulus Program READY_4" 



USING \!B[7mSECOND\lB[0m CLIP. 

USING \lB[7mSECOND\lB[0m CLIP. 

USING \lB[7mSECOND\lB[0m CLIP." 



(continued on the next page) 



Figure 4-136: Stimulus Program (ready_4) - continued 
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! Setup measurement device. 

podsetup 'enable -ready* "off" 
podsetup 'report power* "off" 
podsetup 'report forcing' "off" 
podsetup 'report intr' "off" 
podsetup 'report address' "off" 
podsetup 'report data' "off" 
podsetup 'report control* "off" 
reset device measure_dev 
reset device stimulus_dev 
sync device measure_dev, mode "int" 
sync device stimulus_dev, mode "int" 

if measure_ref = "U4" then 

storepatt device "U4", pin 12, patt "10111" 

storepatt device "U4", pin 13, patt "11101" 

storepatt device "U45", pin 6, patt "00000" 

storepatt device "U45", pin 3, patt "00000" 

else if measure_ref = "U5" then 

storepatt device "U5", pin 1, patt "11111" 

storepatt device "U17", pin 9, patt "10101" 

else if measure__ref = "U17" then 

storepatt device "U4", pin 12, patt "10111" 

storepatt device "U4", pin 13, patt "11101" 

end if 

I Provide stimulus to UUT using I/O module to overdrive. 

arm device measure_dev 

if measure_ref = "U4" then 

writepatt device "U45,U4", mode "pulse" 
else if measure_ref = "U5" then 

writepatt device "U17,U5", mode "pulse" 
else if measure_ref = "U17" then 

writepatt device "U4", mode "pulse" 
end if 
readout device measure_dev 

podsetup 'enable -ready' "on" 
end program 



Figure 4-136: Stimulus Program (ready_4) - continued 
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STIMULUS PROGRAM NAME: READY_4 

DESCRIPTION: SIZE: 78 BYTES 



Response Data 



Node Learned Async ClJc Counter Priority 

Signal Src With SIG LVL LVL Mode Counter Range Pin 

U4-11 I/O MODULE 0015 1 TRANS 

U5-3 I/O MODULE 000A 1 TRANS 



Figure 4-137: Response File (ready_4) 



4-369 



Ready Circuit 



program ready_5 



t I t t t t ! t II I I 1 I i i t t t t J I t I I 1 1 I I i 1 1 1 t I I I I 1 1 ! I I I i t I I i t t I 1 I I I I I I I I I I I | ! j MM 



STIMULUS PROGRAM characterizes the ready circuit. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover () program is executed to 
resynchronize the bus controller and the pod. 



TEST PROGRAMS CALLED: 
recover () 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out 
of sync with the bus control- 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 



checkjneas (device, start, stop, clock, enable) 

Checks to see if the measure- 
ment is complete using the 
TL/1 checkstatus command. If 
the measurement times out then 
redisplay connect locations. 

GRAPHICS PROGRAMS CALLED: 
(none) 



Local Variables Modified: 
done 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulus_dev 

M I I 1 II 1 I 1 1 1 M M 1 1 I 1 IT II t M I I I I I I I I M I t I It I 1 M t M M II I I I 1 1 1 M I I I M J M I I 



returned from check_meas() 



Reset to Zero 



Measurement device 

Stimulus device (overdrives) 



(continued on the next page) 



Figure 4-138: Stimulus Program (ready_5) 
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!!!!!!!!!!!! ! ! !!!!!!! II !!!!!! I ! ! I !!! !!!!!!!!!!!!!!!!!! ! I !!!!!!!!! I! I ! ! ! ! ! 
! Main Declarations ! 

t t t t I I J I I t J J !| t J t t t t t 1 t t 1 t t I J t t t I I 1 t 1 t J t t t 1 J I t I t t 1 J t ! It t 1 M J t M ! I I I I ! I ! ! J 

declare global numeric recover_times 
declare numeric done = 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!>!!!!!!!!!!!!!! 
! FAULT HANDLERS: ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

handle pod_timeout_enabled_line 

recover () 
end handle 
handle pod_timeout_recovered 

recover { ) 
end handle 

! I ! 1 ! ! ! ! ! i !!!!!!!!!!!!!!!!!!!! !! ! ! ! I I I I I I ! ! I I I I I !! !!!!!! I !!!!!!!!!! I! ! ! ! ! 
! Main part of STIMULUS PROGRAM ! 

!!!!!!!!!!!!!!!!!!!!!!!! I !!! I !!!!! I !!!!!!!!!!!!!!!!!!!!!!!!!!!!! II !!!!!! ! 

recover__times = 

! Let GFI determine the measurement device. 

if {gfi control) - "yes" then 
measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print " (Chose U5 or U17) " 

measure_ref = "" \ input measure_ref 

measure_dev = clip ref measure_ref 
end if 
print "Stimulus Program READY_5" 

I Set addressing mode and setup measurement device. 

podsetup 'enable -ready' "off" 

podsetup 'standby function off 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup "report data' "off" 

podsetup 'report control' "off" 

setspace( getspace{ H i/o", "byte" }) 

reset device measure_dev 

sync device measure_dev, mode "ext" 

enable device measure__dev, mode "high" 

edge device measure_dev, start "+", stop "count", clock "-" 

stopcount device measure_dev, count 7 



(continued on the next page) 
Figure 4-138: Stimulus Program (ready_5) - continued 
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! Prompt user to connect external lines. 

if measure_ref = »U17" then 

connect device measure_dev, start "U4-11", clock "Ul-10", common "gnd" 
else 

connect device measure_dev, start "U17-9", clock "Ul-10", common "gnd" 
end if 

! External lines determine measurement. 

loop until done = 1 

arm device measure_dev 
read addr 

done = checkjneas (measure_dev, "U4-11", "*", "Ul-10", "*") 
readout device measure_dev 
end loop 

clearoutputs device measurejdev 
podsetup 'standby function on' 
podsetup 'enable -ready' "on" 

end program 



Figure 4-138: Stimulus Program (ready_5) - continued 
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STIMULUS PROGRAM NAME: READY_5 
DESCRIPTION: 



SIZE: 



69 BYTES 



Response Data 



Node Learned 
Signal Src With 

U17-11 I/O MODULE 



Async Clk Counter Priority 

SIG LVL LVL Mode Counter Range Pin 

1 TRANS 1 



W^# 



Figure 4-139: Response File (readyJS) 
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program ready_6 



i i i i ! I I M J J t j t t t t t t I I I I I I I I i i ? i t t I i i i t n t t t t t t t i t t I I I I i t J i t i t t t t i t j i t i t 



STIMULUS PROGRAM to wiggle all address lines from the uP. 

Stimulus programs and response files are used by GFI to backtrace 
from a failing node. The stimulus program must create repeatable UUT 
activity and the response file contains the known-good responses for 
the outputs in the UUT that are stimulated by the stimulus program. 

This stimulus program is one of the programs which creates activity 
in the kernel area of the UUT. These programs create activity with 
or without the ready circuit working properly. Because of this, all 
the stimulus programs in the kernel area must disable the READY input 
to the pod, then perform the stimulus, then re-enable the READY input 
to the pod. The 80286 microprocessor has a separate bus controller; 
for this reason, disabling ready and performing stimulus can get the 
bus controller out of synchronization with the pod. Two fault 
handlers trap pod timeout conditions that indicate the bus controller 
is out of synchronization. The recover () program is executed to 
resynchronize the bus controller and the pod. 



TEST PROGRAMS CALLED: 
recover () 



GRAPHICS PROGRAMS CALLED: 
(none) 

Global Variables Modified: 
recover_times 

Local Variables Modified: 
measure_dev 
stimulus_dev 

J ! 1 t t t I t t t t t t t t t I t t t t t t t t I t I 



The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases the pod can get out! 
of sync with the bus control- 
ler. The recover program 
resynchronizes the pod and the 
bus controller. 



Reset to Zero 



Measurement device 
Stimulus device (overdrives) 
i t t t t t i t t 1 1 1 t t t I i t t 1 I I I I I I 1 I ! ! I I t t 1 1 1 I 1 1 1 1 1 



(continued on the next page) 



Figure 4-140: Stimulus Program (ready_6) 



4-374 



Ready Circuit 



© 



! ! i i m i t t t t t t t i i j j j j j 1 i t t i i i t j t t t t t t t j » ! t i i t j i i i i i ] j t t t t t i i i t t i t t t i t t t i t t 
i Main Declarations ! 

I i i i i i i j I I j i I t t j t t t j j j j j j j j j t r i ; i i i i t t t t t t j t i t t ; j t t i ; j j j j j r j t Minn!!!!! 

declare global numeric recover_times 
declare numeric done = 

M I I I I I I I I I I I I I I I I j ; ; ;; ; M j J J J J J | | j J J J J J j j i j j j t t j j i j j i i t t j j j j j j i t t t t 1 I I I I 
! FAULT HANDLERS: ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

handle pod_timeout_enabled_line 

recover () 
end handle 
handle pod_timeout_recovered 

recover!) 
end handle 

m t t t t t ! ! m t t j i j i j j j j j i I t i i j i i i i ! i i i i I i i i j m t t j j j j t t t j j j j j t t t j j j j j j t j t t t t 
! Main part of STIMULUS PROGRAM ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

recover_times = 

! Let GFI determine the measurement device. 

if (gfi control) = "yes" then 

measure_dev = gfi device 

measure_ref = gfi ref 
else 

print "Enter reference name of part to measure:" 

print » (Chose U5 or U17) " 

measure_ref = "" \ input measure_ref 

measure_dev = clip ref measure_ref 
end if 
print "Stimulus Program READY_6" 

! Set addressing mode and setup measurement device. 

podsetup "enable -ready' "off" 

podsetup 'standby function off 

podsetup 'report power' "off" 

podsetup 'report forcing' "off" 

podsetup 'report intr' "off" 

podsetup 'report address' "off" 

podsetup 'report data' "off" 

podsetup 'report control' "off" 

setspace ( getspace( "i/o", "byte" )) 

reset device measure_dev 

sync device measure_jdev, mode "ext" 

enable device measure_dev, mode "high" 

edge device measure_dev, start "+", stop "count", clock "-" 

stopcount device measure_dev, count 4 



(continued on the next page) 
Figure 4-140: Stimulus Program (ready_6) - continued 
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! Prompt user to connect external lines. 

if measurejref « M U17" then 

connect device measure_dev, start "U4-11", clock "Ul-10", common "gnd" 
else 

connect device measure_dev, start "U17-9", clock "Ul-10", common "gnd" 
end if 

I External lines determine measurement. 

loop until done = 1 

arm device measure_dev 
read addr 

done « check_meas (measure_dev, "U4-11", "*", "Ul-10", "*") 
readout device measure_dev 
end loop 

clearoutputs device measure_dev 
podsetup 'standby function on' 
podsetup "enable -ready' "on" 

end program 



Figure 4-140: Stimulus Program (ready_6) - continued 



4-376 



Ready Circuit 



STIMULUS PROGRAM NAME: READY_6 

DESCRIPTION: SIZE: 70 BYTES 

Response Data 

Node Learned Async Clk Counter Priority 

Signal Src With SIG LVL LVL Mode Counter Range Pin 

U17-11 I/O MODULE 10 TRANS 






Figure 4-141 : Response File (ready jB) 
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Summary of Complete Solution for 
Ready Circuit 



4.14.8. 



The entire set of programs and files needed to test and GFI 
troubleshoot the Ready Circuit functional block is shown below. 
The format below is similar to a 9100A/9105A UUT directory 
(you could consider the functional block to be a small UUT), but 
in addition shows the use of each program and the location in 
this manual for each file. 

UUT DIRECTORY 
(Complete File Set for Ready Circuit) 



Programs (PROGRAM): 

TST_READY 

READYJ 

READY__2 

READY_3 

READY_4 

READY_5 

READY 6 



Functional Test 
Stimulus Program 
Stimulus Program 
Stimulus Program 
Stimulus Program 
Stimulus Program 
Stimulus Program 



Stimulus Program Responses (RESPONSE): 

READY_1 
READY_2 
READY_3 
READY_4 
READY_5 
READY_6 

Node List (NODE): 
NODELIST 

Text Files (TEXT): 



Section 4.14.5 
Figure 4-130 
Figure 4-132 
Figure 4-134 
Figure 4-136 
Figure 4-138 
Figure 4-140 



Figure 4-131 

Figure 4-133 
Figure 4-135 
Figure 4-137 
Figure 4-139 
Figure 4-141 



Appendix B 



Reference Designator List (REF): 
REFLIST 

Compiled Database (DATABASE): 
GFIDATA 



Appendix A 



Compiled by the 9 100A 
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OTHER FUNCTIONAL BLOCKS AND CIRCUITS 4.15. 

The 9100A/9105A provides the capability to handle a number of 
special circuits or situations. Among these are watchdog timers 
forcing lines, feedback loops, and in-circuit component testing. 



Watchdog Timers 4.1 5.1 . 

Watchdog timers usually interfere with testing and 
troubleshooting. If your UUT has a watchdog timer, your test 
procedure or program must disable it before performing tests. 

Many watchdog timers initiate a master reset when they detect 
incorrect activity. Others may use a high-priority interrupt line 
to reset the system. 

Whenever possible, physically disable the watchdog timer with a 
jumper or switch provided for that purpose. If the watchdog 
timer cannot be disabled at the UUT, the 9100A/9105A may be 
able to ignore it with the SETUP POD REPORT FORCING 
SIGNAL ACTIVE OFF keypad command, or disable it with a 
command like SETUP POD ENABLE READY ON/OFF. Be 
very careful, however, when doing this. Read the precautions 
about these commands in Section 4.15.2, "Forcing Lines." 



Forcing Lines 4.15.2. 

In some situations, forcing lines must be disabled (disconnected 
from the pod microprocessor) during a test. You can do this 
with the SETUP POD ENABLE READY ON/OFF keypad 
command ("READY" is a pod-dependent choice; some pods 
may call this line by a different name). 

Exercise care whenever you disable a forcing line. Write or read 
commands to circuits that generate wait states through a Ready 
line may become unpredictable after the Ready line is disabled at 
the pod. 
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In addition to disabling forcing lines, you can also ignore them. 
The SETUP POD REPORT FORCING SIGNAL ACTIVE OFF 
keypad command will prevent the reporting of forcing lines. In 
this mode, the pod behaves normally but forcing conditions are 
not reported by the pod to the 9100A/9105A. 

Exercise care with this mode also. The pod's hardware 
performance is not affected and the pod will continue reacting to 
the forcing line. If the UUT generates a permanent wait state 
using a forcing line, the pod will halt and the system will display 
a timeout message. Other fault-indicating signals on your UUT 
will also be ignored if the forcing line is disabled. Be sure that 
your UUT hardware is not affected by the same forcing line. 



Breaking Feedback Loops 4.15.3. 

Microprocessor-based systems often have several feedback 
loops. The microprocessor and the components tied to the data 
and address buses form a large feedback loop. Most of the 
loops in the system will be broken when the microprocessor is 
replaced by the pod, because the pod can selectively ignore or 
report conditions of status and forcing lines. However, there 
may be additional loops which are not broken by the pod. 

Figure 4-125 shows a feedback loop in the Ready functional 
block of the Demo/Trainer UUT. The READY output (Ul-4) is 
fed back as an input at U4-12. 

To test a functional block that contains a feedback loop, drive all 
of its inputs, including the inputs connected to outputs that form 
the feedback loop, and measure the outputs. Use the I/O module 
to overdrive inputs while measuring signature, level, and count 
at the outputs. 



Visual and Acoustic Interfaces 4.1 5.4. 

Some circuits, such as LEDs and beepers, have both electrical 
characteristics and visual or acoustic characteristics . In general, 
stimulus programs should ignore the visual or acoustic 
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characteristics and measure only the electrical characteristics . 
The functional tests should prompt the test operator to verify the 
visual or acoustical characteristics . 

If the functional test fails, use the gfi test command. If gfi test 
fails, start GFI troubleshooting. If the functional test fails and 
gfi test passes, the part is bad, since the part operates incorrectly 
but the electrical signals at the part are good. 

In the case of the Parallel I/O functional block on the 
Demo/Trainer UUT, the functional test includes a prompt to the 
operator to verify the correct display on the LEDs. If the LEDs 
fail, the Parallel I/O functional test should perform a gfi test, 
which will run the stimulus programs and check the electrical 
properties. If gfi test passes (when the Parallel I/O functional 
test failed), it means that the electrical characteristics are good 
but the display is bad. The LEDs are bad and the operator 
should be prompted to replace them. If the gfi test fails, GFI 
troubleshooting can begin at the pin where the gfi test failed. 



In-Circuit Component Tests 4.15,5. 

If you wish, you can write TL/1 programs to test individual 
components rather than using the GFI to do so. These in-circuit 
component tests use a sequence of ones and zeroes defined with 
the TL/1 storepatt command and executed by the TL/1 writepatt 
command to overdrive the inputs of the component to be tested 
while measuring the signatures or level histories of its outputs. 
A test operator runs these tests by using the EXEC key to run 
the required program. 
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UUT Go/No-Go 
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PROGRAMMED GO/NO-GO FUNCTIONAL 

TESTING 5.1. 

The UUT go/no-go test is the third of four modular levels in 
programming the 9100A, as shown in Figure 5-1. In this third 
level, the go/no-go test determines whether the UUT is good 
(passes) or bad (fails). The go/no-go test combines built-in 
functional test commands with functional tests designed by the 
programmer. 

The go/no-go test is simple because it builds on the tests of 
functional blocks. It determines only whether the entire UUT is 
good or bad. It does not determine which functional block is 
causing a failure. 



CREATING A PROGRAMMED GO/NO-GO 

FUNCTIONAL TEST 5.2. 

Suppose a UUT has 14 functional blocks and a functional test is 
defined for each of them. One way to create a go/no-go test is to 
perform all 14 functional tests. Some blocks, however, can be 
tested indirectly by testing other blocks. For example, the bus 
buffer is assumed to be good if the ROM, RAM, and other 
blocks pass their tests. Therefore, a second way to create the 
go/no-go test is to perform functional tests only on functional 
blocks which cannot be tested indirectly by testing other blocks. 
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Level 1 

• Stimulus Programs for Nodes 
•Learned Node Responses 

from Known-Good UUT 
■ Node List and Reference 

Designator List (Both Optional) 



Level 2 



Functional Tests of 

Entire Functional Blocks 



:; ; ;Leve1i3:;;; 



; Gb/No-.GoTest 
!; : for the Entire. UUT 



n 



Level 4 



Go/No-Go Test 
for the Entire UUT, 
with Fault Isolation 
to the Block Level 



Figure 5-1 : UUT Go/No-Go Functional Testing (Level 3) 
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Figure 5-2 shows the steps used to reach a go/no-go status 
decision. Care must be taken to ensure that your go/no-go test 
really does test the UUT for all possible faults. 

Figure 5-3 shows the structure of a go/no-go functional test for 
the Demo/Trainer UUT. For this UUT, only six functional 
blocks need to be tested for the go/no-go functional test of the 
UUT: Microprocessor Bus, RAM, ROM, Parallel I/O, Serial 
I/O, and Video. The microprocessor bus test is run first because 
it is built-in, fast, and provides excellent diagnostic information, 
A failure on the microprocessor bus will cause most other 
circuits to fail, so it is most efficient to check this functional 
block first. 

In the Demo/Trainer UUT, the following functional blocks are 
tested indirectly by the go/no-go test: 

Clock and Reset 
Ready Circuit 
Interrupt Circuit 
Bus Buffer 

Dynamic RAM Timing 
Address Decode 
Video Control 
Video RAM 

Figure 5-4 is a listing of the go/no-go functional test program for 
the Demo/Trainer UUT, It calls the functional test for each of 
the functional blocks which must be tested directly for the UUT 
go/no-go functional test to be complete. The remaining 
functional blocks are tested indirectly; if they fail, one of the six 
blocks that is tested by the go/no-go test will fail also. 



EVALUATING TEST EFFECTIVENESS 5.3. 

The purpose of the go/no-go test is to determine whether the 
UUT is good or bad. Two measures are frequently used to 
evaluate how well a go/no-go functional test performs: node 
activity and fault coverage. Node activity is important because 
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Select a Functional 
Block Which Cannot 
be Tested Indirectly 
by Testing Another 
Functional Block 



Execute the Functional 

Test for the Functional 

Block 



Yes 




Figure 5-2: Go/No-Go Test Sequence 
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Q 



Test Microprocessor Bus 



Test RAM 



Test ROM 



Test Parallel I/O 



Test Serial I/O 



Test Video 



Figure 5-3: Demo/Trainer UUT Go/No-Go Test 



5-5 



program go_nogo 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!■!!!!!!!!!!! H !!!!!!! I ! !!!!!!!!!!!!!!!!!!! ! 



The Go/No-Go program is the highest level of the functional testing 
and fault handlers. The purpose of the Go/No-Go test is to determine 
whether the UUT is good or bad. This program executes six programs 
which test the six major functional blocks (Microprocessor Bus, ROM, 
RAM, Parallel I/O, Serial I/O, and Video functional blocks) . 
By testing the six major functional blocks, the remaining 
functional blocks are indirectly tested. 



TEST PROGRAMS CALLED: 
test_bus () 



Test the microprocessor bus, 
buffered bus, and address 
select logic. 

Test the ROM functional block 
of the Demo/Trainer UUT. 

Test the RAM functional block 
of the Demo/Trainer UUT. 

Test the PARALLEL I/O 
functional block of the 
Demo/Trainer UUT. 

Test the SERIAL I/O 
functional block and the 
Interrupt Circuit functional 
block of the Demo/Trainer UUT. 



Test the VIDEO circuit of the 
Demo/Trainer UUT. 
! ! ' ! ! t t t ; i t J | ] i i i i i i t t t t t t t t t t t i t i i i i i t t t t t t m t t i t i i i i t i t i t t t t t t t t t m ) i 



test ram 



test_pia 



test_rs232 () 



test_video () 



i t t t t i t 



I t t t t t t t M I I I I I 



SETUP 
t t i i i i 



AND 
i i i 



SYSTEM 

T M t I t t 



INITIALIZATION ! 

t t t t t I I I I I I ! t I I 



podsetup 'report power' "on" 

podsetup 'report intr' "off" 

podsetup 'report address' "on" 

podsetup 'report control' "on" 

podsetup 'report data' "on" 

podsetup 'report forcing' "on" 



Turn on reporting functions except 
interrupt which is tested in the 
SERIAL I/O test (test rs232) . 



t r n J J M t t ! I J J I j I J j T j J J J t 1 1 I t J t 1 1 j J 1 t t t 1 1 1 I J J J t t t I t 1 t I t t I I I ! ! ! t t J I I t 

! This is the go/no-go test which runs the major functional tests. ! 
! i i i i i i i i t i i t t t t i i i i i i i i i i i i t t r t t t t t t t t t t m t i i i i i t t r i i i i i i t m r i i i i t t 



gfi clear 
connect clear 



■yes" 



! CLEAR ALL GFI RECOMMENDATIONS 
! Clear all connect information. 



execute test_bus{) 
execute test_rom() 
execute test_ram() 
execute test_pia() 
execute test_rs232() 
execute test_video() 
end program 



Figure 5-4: Go/No-Go Test for Demo/Trainer UUT 
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each node on the UUT must be exercised for a thorough 
functional test. 

However, activity on each node is not a sufficient evaluation of 
test effectiveness. In addition, you need to evaluate how well 
your test detects faults in the UUT. This is done by injecting 
faults (such as stuck lows, stuck highs, intermittent highs, or 
intermittent lows) at each node in the UUT while running your 
functional test to see if the test fails. The 9100A/9105A probe 
(used as a source) provides a convenient tool for this purpose. 

Fault coverage is the percentage of faults that will be detected by 
the functional test software. It is often measured as the ratio of 
the number of nodes where injected faults can be detected by a 
test to the total number of nodes in the UUT. This ratio is 
usually expressed in percent. If the fault coverage is not high, 
you can analyze the pattern of faults that are not detected to 
determine additions to your test program to increase the fault 
coverage. 



EXECUTING UUT SELF-TESTS 5.4. 

Self-test routines contained in UUT memory can be executed 
from the 9100A/9105A by pressing the RUN UUT key at the 
operator's keypad and entering the UUT's starting address of 
the routine. These self-test routines can also be run from TL/1 
programs by using the runuut command. Self-test routines 
typically save their test results in UUT RAM. The 
9100A/9105A can later read the appropriate RAM addresses to 
get these results. 

An I/O module can generate one hardware breakpoint (system 
interrupt) upon detection of any user-defined combination of 
logic-highs and logic-lows on selected I/O module lines. This 
feature may be invoked at the operator's keypad (SET I/O MOD 
COMPARE WORD command), or through program execution. 
Once set up for a breakpoint, the I/O module continuously 
monitors the specified lines while other functions (such as RUN 
UUT) are performed. When the breakpoint event occurs, RUN 
UUT execution halts. A breakpoint message will interrupt any 
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current system activity. If a program is being executed, it may 
redirect the breakpoint message through a fault condition 
handler, as described in Section 6 of this manual. 

A complete functional test for a UUT might begin with the BUS, 
RAM, and ROM tests, followed by execution of UUT self-test 
routines. By using RUN UUT breakpoints to detect addresses, 
data, and other UUT logic levels, the program can integrate the 
UUTs self-tests with 9100A/9105A functional tests. 

Some pods can also generate UUT breakpoints without using 
the I/O module. For these pods, breakpoint-related softkeys 
appear when the RUN UUT key is pressed. Consult your pod 
manual for these pod-specific breakpoint capabilities, if any. 



EXECUTING DOWNLOADED MACHINE CODE 5.5. 

After part of the UUT RAM has been tested and found to be 
good, machine code can be downloaded to the tested RAM and 
executed. The machine code may be downloaded using a series 
of WRITE commands or the WRITE BLOCK command, which 
downloads an entire Motorola-format user file. 

After the code is downloaded, you can execute it with the RUN 
UUT command, specifying the code's starting address. 
Although most testing can be done efficiently through the TL/1 
test language, downloading machine code is useful when the 
code for a test already exists, when the testing must be done at 
machine-code speeds, or when a feature not supported by the 
pod must be used as part of the test 

The pod's microprocessor bus cycles are actually done at full 
UUT speed. The 9100A/9105A, however, is often slower than 
the UUT. For example, when the system performs a looping 
READ, each bus cycle is at full UUT speed but individual read 
operations are not done one immediately after the other. 
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Section 6 

Identifying a Faulty 
Functional Block 



After the go/no-go test determines that a UUT is faulty, the next 
step is to identify the failing functional block. Doing so before 
starting to troubleshoot will greatly improve troubleshooting 
efficiency because troubleshooting can begin closer to the failure 
and will take less time to reach the failing node. In addition, 
fault detection will be more accurate because the diagnostic test 
can check for special types of faults, such as bus contention, 
before troubleshooting begins. 

Programs that identify faulty functional blocks are called 
diagnostic programs. Diagnostic programs, which are a subset 
of troubleshooting procedures, build on the UUT go/no-go test, 
functional tests of blocks, and stimulus programs. They are the 
last of the four modular levels in programming the 9100A, as 
shown in Figure 6-1. In this fourth programming level, fault 
condition handlers and gfi hint commands are added to the UUT 
go/no-go test to create a diagnostic program that traps faults and 
initiates tests of functional blocks that may be responsible for the 
fault, thereby isolating the block that is causing the UUT to fail. 
In addition, a failing output of the faulty block is identified as a 
starting point for backtracing toward the fault that causes the 
block to fail. At that point, GFI troubleshooting (the GFI key 
on the operator's keypad) can be used to backtrace to the bad 
node or component. 
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Level 1 

■ Stimulus Programs for Nodes 
- Learned Node Responses 

from Known-Good UUT 

■ Node List and Reference 
Designator List (Both Optional) 



Level 2 



Functional Tests of 
Entire Functional Blocks 



Level 3 



Go/No-Go Test 

for the Entire UUT 



Level 4 



Go/No-Go Test 
for the Entire UUT, 
with Fault Isolation 
to the Block Level 



Figure 6-1 : Diagnostic Programs (Level 4) 
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STRATEGY OF DIAGNOSTIC PROGRAMS 6.1. 

The first step in developing a diagnostic strategy is to draw a 
diagram showing the major functional blocks used in the go/no- 
go functional test. Next, show all other functional blocks that 
provide input to these major functional blocks. Figure 6-2 
shows such a diagram for the Demo/Trainer UUT. The figure 
shows six sets of functional blocks, one for each major 
functional block tested by the go/no-go functional test. The 
blocks on the left provide input to the blocks on the right, and 
the blocks tested by the go/no-go functional test are on the right 
side of each set. 

The task of the diagnostic program is to select a failing 
functional block for troubleshooting and to generate an 
appropriate starting point (or points) where GFI can begin 
automated troubleshooting. When a major functional block 
fails, you know that one or more outputs of the block are bad. 
But it doesn't necessarily mean that the block itself is bad; bad 
inputs to the major functional block may be causing the block to 
fail. How do you continue from there to isolate the failing block 
and select an efficient starting point for GFI? 

One diagnostic strategy is to test blocks that provide input to the 
failing major block. Isolating the block causing a failure 
involves tracing from the right-hand side toward the left, testing 
each block in the path until one is found with good inputs and 
bad outputs. This strategy works best when the string of blocks 
leading up to a major block is short. Such is the case for most 
of the sets of blocks in Figure 6-2. 

A second diagnostic strategy, helpful when you have a longer 
string of blocks leading up to a failing major block, is to divide 
the blocks in half and begin testing a block halfway between the 
first block in the string and the major block at the end. If the 
middle block passes, keep dividing the failing string of blocks in 
half and testing a middle block. If the middle block fails, test the 
blocks to the left starting at the middle block. This second 
strategy would be appropriate for the Video set of blocks in 
Figure 6-2. 
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(continued on the next page) 



Figure 6-2: inputs to Functional Blocks 
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Figure 6-2: Inputs to Functional Blocks- continued 
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Another strategy, used when a fault is likely to be near a failing 
output pin of the failing major block, is to begin GFI backtracking 
directly from the failing output pin, without checking the inputs 
to the major functional block. 

Diagnostic programs can speed up troubleshooting by starting 
GFI closer to the actual problem. On the other hand, isolating 
the failure to a very small area may require more time than is 
saved in reduced troubleshooting time. There is a balance 
between isolating the failure to a very small area and doing no 
isolation of the failing circuit. Decisions on when to start GFI 
and when to isolate the failure to a smaller area depend on your 
UUT and the relative cost of additional programming effort 
compared to the resulting savings in troubleshooting time. 



IMPLEMENTING THE STRATEGY FOR 

DIAGNOSTIC PROGRAMS 6.2. 

Figure 6-3 shows a typical process to implement a diagnostic 
program strategy. The diagnostic program executes a functional 
test for each major functional block. If a fault condition is 
generated during the test, the major functional block is possibly 
faulty. To verify this suspicion, the inputs to the functional 
block are checked. If the inputs are all good, then the major 
functional block is indeed faulty. However, if one of the inputs 
to a major functional block is not good, the fault probably lies in 
the functional blocks which provide input to the major functional 
block. In this case, the input functional blocks become the 
suspect blocks and their inputs are checked. This process 
continues until a block is found with all good inputs but a bad 
output. 

When this faulty functional block is identified, appropriate GFI 
hints are generated to indicate the node (or nodes) where GFI 
should start troubleshooting. 
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Figure 6-3: Identifying a Faulty Functional Block 
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DIAGNOSIS USING FAULT CONDITION 

HANDLERS 6.3. 

Fault condition handlers provide the means for communicating 
9100A/9105A functional test failure information to the operator 
for keystroke troubleshooting or to GFI for automated 
troubleshooting. 



What are Fault Condition Handlers? 6.3.1 . 

A fault condition is generated or "raised" in one of two ways: 

• A built-in TL/1 function is run, and the UUT does not 
respond correctly. For example, a microprocessor address 
line cannot be driven to logic-high during a read or write 
operation. 

• A fault command is executed in a TL/1 program. 

A fault condition handler is a TL/1 procedure, called by a fault 
condition of the same name, that responds in some way to the 
fault condition. For example, the handler might try to determine 
the cause of the fault. 

Each fault condition has a name. Fault conditions created by 
built-in functions have defined names and parameters, listed in 
TL/1 Reference Manual appendices. Fault conditions created by 
your fault commands may have any name, including the same 
name used by the built-in functions. 

When a fault condition is raised, the system halts execution of 
the current program. If your program contains a fault condition 
handler with the same name as the fault condition, the program 
statements inside the handler are executed. After the handler is 
finished, execution of your program resumes where it left off. 

If your program does not contain an appropriate fault condition 
handler, execution of the program terminates and its calling 
program (if any) is searched for a fault condition handler with 
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the specified fault condition name. This process continues until 
an appropriate handler is found. If no handler is found, a fault 
message will appear on the operator's display. 

For more information on fault condition handlers, see Section 
3.7 of the Programmer's Manual 



Using Fault Condition Handlers 6.3.2. 






j^"^ 
%& 



The UUT go/no-go test should test only those functional blocks 
that cannot be tested indirectly by other blocks. When the 
go/no-go test detects a failure, the diagnostic program is used to 
identify the failing block and to identify a failing node as a 
starting point for troubleshooting. 

To use fault condition handlers in a diagnostic program, you 
need to do two programming tasks for each handler: 

1. Use the fault command (with an appropriate fault 
condition that you create) to generate the fault 
condition if a test (or part of a test) of a functional 
block fails. For example, if the diagnostic program 
finds that the functional test of the video output 
circuitry fails, you might choose to generate a fault 
condition named video _output 

2. Create a handler for this fault condition. The handler 
should check other input blocks to isolate the failing 
functional block. It might also do further testing to 
narrow down the zone of failure within a failing 
functional block. And the handler will generate the 
appropriate starting point for GFI by using the gfi 
hint command. 



A Diagnostic Test Example 6.3.3. 

Suppose the video circuitry is failing. Testing begins with 
execution of the go/no-go2 program, listed in Section 6.4 of this 
manual. This program has many fault condition handlers at the 
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beginning, and it has six execute statements at the end that 
actually execute the go/no-go test. Each of these execute 
statements executes a different functional test program for a 
major functional block. And each of these functional test 
programs include the necessary fault condition handlers to 
generate GFI hints appropriate for the fault condition 
encountered (a listing for each of these programs is contained in 
Section 6.5 of this manual). The GFI hints are very important to 
the troubleshooting process; they are the means by which the 
9100A/9105A communicates the results of its functional testing 
to provide efficient starting points for GFI troubleshooting. 

Suppose that the failing video circuitry does not affect any of the 
six major functional blocks except test_video2. In this case, 
testjbus2, test_rom2, test_ram2, testj)ia2 f and test_rs232b all 
pass, but test_video2 fails. The test_video2 test is really the test 
of the Video Output functional block. If this test fails, a video 
fault condition is generated (suppose the video _scan fault 
condition is generated). Since the test_video2 program has a 
handler for video _scan, the program statements inside this 
handler are executed. 

Once the hints to GFI are passed, execution of the video fault 
condition handler (video_scan) ends, the test program 
(test_video2) ends, and the diagnostic program (go_nogo2) 
ends. A message appears on the operator's display saying that 
GFI hints have been generated, and that GFI should be run. 

The diagnostic program is structured so that only one failure is 
isolated at a time. The problem should be isolated with GFI and 
fixed when it is detected. It is appropriate to repair an isolated 
fault before testing any further, since apparent multiple failures 
often result from one physical problem on a board. For 
example, a short between two nodes can appear as two failures. 
After a fault has been repaired, the diagnostic program should be 
run again to find other faults or to verify that no more faults can 
be found. 



6-10 



© 



DIAGNOSTIC PROGRAM FOR THE 
DEMO/TRAINER UUT 



6.4. 



program go_nogo2 



W 



MiiHitnmnii 
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The Go/No-go program is the highest level of the functional testing 
and fault condition handlers. The purpose of the Go/No-go test is to 
determine whether the UUT is good or bad. This program executes six 
programs which test the six major functional blocks (Microprocessor 
Bus, ROM, RAM, Parallel I/O, Serial I/O, and Video) . By testing the 
six major functional blocks, the remaining functional blocks are 
indirectly tested. 

If the Go/No-go test detects a faulty UUT, further fault isolation is 
performed to isolate which circuit is causing the failure. The fault 
condition handlers in the Go/No-go program and the other functional 
test programs perform the fault isolation. The fault condition 
handlers included in this program are handlers for those fault 
conditions which may occur during any of the six major functional 
tests. 

The major functional test programs include fault condition handlers 
for fault conditions which are only generated within that program. 
The first three programs (TEST_BUS, TEST_ROM, and TEST_RAM) use 
built-in TL/1 tests and the built-in fault condition handlers that 
are documented in the 9100/9105A TL/1 Reference Manual. 



TEST PROGRAMS CALLED: 
test bus2 



test_pia2 



test rs232b 



test video2 



Test the microprocessor bus, 
buffered bus, and address 
select logic. 

Test the ROM functional block 
of the Demo/Trainer UUT. 

Test the RAM functional block 
of the Demo/Trainer UUT. 

Test the PARALLEL I/O 
functional block of the 
Demo/Trainer UUT. 

Test the SERIAL I/O functional 
block and the Interrupt 
Circuit functional block of 
the Demo/Trainer UUT. 

Test the VIDEO circuit of the 
Demo/Trainer UUT. 

The 80286 microprocessor has a 
bus controller that is totally 
separate from the pod. In 
some cases, the pod can get 
out of sync with the bus 
controller. The recover 
program resynchronizes the pod 
and the bus controller. 
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! FUNCTIONS CALLED: ! 

I retry_access (access, addr, control) This function is executed when! 

! a pod_timeout_recovered fault ! 

! condition occurs. This ! 

! function repeats the attempted! 

! access that failed and ! 

I determines if the access can ! 

! be sucessfully repeated. ! 

t ! 

! Global Variables Modified: ! 

! recoverjzimes Reset to Zero ! 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

!!!!!! MM! I 1 !!!!!!!!!!! I !!!!!!!! H !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I ! H 
! Main Declarations I 

M M M M M M M M M M M M M M M M M ! M M M M M M M M M M M M M M M M M M M 



declare 

global numeric recover_times 
end declare 



Count of executing recover (). 



i t | t i i i i i t t t t t t j I t t it i t it i t J i i j t J i t t i j t i t i i t i t i i i i i j t it t i i j i i i r ii i t i t t 
GENERAL PURPOSE FAULT CONDITION HANDLERS 

The built-in fault conditions M pod__addr_tied", "pod__ctl_tied H , 
"pod_data_incorrect" and pod_data_tied are generated when the pod 
detects a stuck or tied line at the pod socket. These fault 
conditions are not handled because the diagnostic message for these 
faults cannot be made better by additional testing. If one of these 
fault conditions occurs, the built-in fault message will be displayed 
and the UUT needs to be repaired. 

i m i t t t t i t t t t t t t i t i I t t !!!!!!!! M M M M M ! M M M M M M M ! M M ! ! ! M ! ! ! ! ! 



handle pod_forcing_active (mask) 

declare string mask 

declare global numeric tlo 

declare string clear_screen = ,, \1B[2J" 

print on tlo ,clear_screen, "POD Forcing Lines Active fault" 

fault forcing_lines mask mask ! Redirect fault 

end handle 

handle pod__interrupt_active (mask) 
declare string mask 
declare global numeric tlo 
declare string clear_screen = "\1B[2J" 
print on tlo , clearjscreen, "POD Interrupt Line Active fault" 

! Get the last two characters of the 64 bit string mask and decode to INTR/NMI 

lines = val (mid (mask, len(mask)-3, 2), 16) 
if (lines and $10) <> then 

execute tst_intrpt() 
else if (lines and 1) <> then 

fault NMI_active 
end if 
end handle 



handle pod_misc_fault 

fault bad_power 
end handle 



! Redirect fault 
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handle podjspecial 
end handle 



handle pod_t imeout_bad_pwr 

declare global numeric tlo 

declare string clear_screen = "\1B[2J M 

print on tlo ,clear_screen, "POD timeout bad power fault" 

fault bad_power ! Redirect fault 

end handle 

handle pod_timeout_enabled_line (mask) 

declare string mask 

declare global numeric tlo 

declare string clear_screen = "\1B[2J" 

print on tlo , clear_screen, "POD Timeout Enabled line fault" 

fault forcing_lines mask mask ! Redirect fault 

end handle 



handle pod_timeout_no_clk 
declare global numeric tlo 
declare string clear_screen 
print on tlo , clear_screen, 
execute tst_clock() 

end handle 



= "\1B[2J" 

'POD Timeout No Clock at POD Pin 31" 

! Test Clock and Reset 



\J 



handle pod_timeout_recovered (access_attempted, ctl, addr) 

declare string access_attempted 

declare numeric ctl = $E0OO0000 

declare numeric addr = $E0000000 

declare global numeric tlo 

declare string clearjscreen = "\1B[2J" 

declare global numeric repeated_timeouts 

print on tlo , clearjscreen, "pod timeout recovered: " 
podsetup "enable -ready' "off" 
podsetup 'enable hold* "off" 
podsetup 'report forcing' "off" 
repeated_timeouts = repeated_timeouts + 1 

! DISABLE all lines that can be enabled, retry access, then turn enable 
! lines on until the access cannot be repeated. The lines that can be 
! enabled on the 80286 are Hold and Ready. 

if repeated_timeouts > 10 then 

fault dead_kernel 
else if retry_access (access_attempted, ctl, addr) fails then 

fault dead_kernel 
else 

podsetup 'enable hold* "on" 

if retry_access (access_attempted, ctl, addr) fails then 

fault hold_circuit 
else 

podsetup 'enable -ready' "on" 

if retry_access (access_attempted, ctl, addr) fails then 
execute tst_decode{) 
execute tst_ready<) 
else 

print on tlo ,clear_screen 
end if 
end if 
end if 
end handle 
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handle pod_timeout_setup 
end handle 



handle pod_uut_power 

fault bad_power 
end handle 



! Redirect fault 



handle iomod_dce 
end handle 

!!!! II !!!!!!!!!!!!!!!!!!!! I! ! 
I Redirected Fault Handlers ! 
t t 1 1 t i t t t i t t i t t t t t t t t t t i t t 1 1 1 



handle forcing_lines (mask) 
declare string mask 
declare global numeric recover_times 

attempt to recover synchronization between pod and bus controller before 
testing the decode, ready or clock circuits. If the recover procedure 
has been executed at least twice, then go ahead and test decode, ready or 
the clock circuit. 



if recover_times < 2 then 

execute recover () 
else 

lines = val (mid (mask, len(mask)-7, 8), 16) 
if (lines and 1) <> then 

execute tst_decode() 

execute tst_ready() 
else if (lines and $10) <> then 

execute tst clock () 
end if 



I Test Clock and Reset 



! The status lines HOLD, PEREQ, BUSY and ERROR are not used in the 

! Demo/Trainer UUT. Display a message if one of these lines is active 

I and wait for the condition to be fixed. 

loop while (lines and $E2) <> 
print on tlo ,clear_screen 
if (lines and 2) <> then 

print on tlo , "HOLD is active; Press RESET to continue" 
else if (lines and $20) <> then 

print on tlo , "PEREQ is active; Press RESET to continue" 
else if (lines and $40) <> then 

print on tlo , "~BUSY is active; Press RESET to continue" 
else if (lines and $80) <> then 

print on tlo , "-ERROR is active; Press RESET to continue" 
end if 

wait time 2000 
end loop 
end if 
end handle 
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handle bad_power 

declare global numeric t2o 
declare string clear_screen = "\1B[2J" 
declare global string messg 
print on t2o ,messg+"FAULT DETECTED" 
loop until (readstatus () and 33D00) = 
fail ($14) 
if (readstatus () and $3C00) = $3C00 then 

print on tlo , clearjscreen, "POD UUT Power" 
print on tlo , "POWER_UP and press RESET on Trainer UUT" 
wait time 2000 

print on tlo , clear_screen, "CONTINUING..." 
else 

if (readstatus () and $100) <> then fault 'CAP failure at POD Pin 52' 
if (readstatus () and $400) <> then fault 'POWER failure at POD Pin 30' 
if (readstatus () and $800) <> then fault 'POWER failure at POD Pin 62' 
if (readstatus () and $1000) <> then fault 'GROUND failure at POD Pin 35' 
if (readstatus () and $2000) <> then fault 'GROUND failure at POD Pin 9' 
end if 
end loop 
untested ($14) 
end handle 



y^J 



!!!!!!!!!!!!!!!!!!!! II I !!!!!!!!!!!! I H !!!!!! I t| !!!!!!! I !!!!■!!!!!!!! I I I! 
Functions 
I I I I I I I I I ! I M I! !! ! ! ! ! ! ! I I I I I I I I I I ! I! ! ! I I I I I ! ! ! ! I I I I ! ! ! ! I ! ! ! ! I I I t t t t t i i i 

function retry_access (ACCESS, ADDR, CTL) 

I Retry last access performed using parameters from fault handlers . 

handle pod_timeout_bad_pwr 

fault 
end handle 

handle pod_timeout_enabled_line 
fault 

end handle 

handle pod_timeout_no_clk 

fault 
end handle 

handle pod_timeout_recovered 

fault 
end handle 

handle pod_timeout__setup 
fault 

end handle 
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declare string ACCESS 
declare numeric CTL 
declare numeric ADDR 

if ADDR <> $£0000000 then 

address » ADDR 
else if CTL <> $E0000000 then 

address = CTL 
else 

address = 
end if 
if ACCESS = "READ" then 

if read addr address fails then fault 
else if ACCESS = "WRITE" then 

if write addr address, data $A5C3 fails then fault 
end if 

end function 

I I I I I I I I I I I I I I I I ! I ! MM I I I I I I I I ! I I ! 
I SETUP AND SYSTEM INITIALIZATION ! 

I 1 1 I I M M ! I I M t M I I t I t t t t ! 1 I I I t M t J 



recover_times = 
execute recover () 



Recover synchronization between POD 
and the 80288 bus controller. 



podsetup 'report power' "on" 

podsetup 'report intr* "off" 

podsetup 'report address' "on" 

podsetup 'report control' "on" 

podsetup 'report data' "on" 

podsetup 'report forcing' "on" 



! Turn on reporting functions except 
! interrupts which is tested in the 
! SERIAL I/O test {test rs232b) . 



m 



I I 1 1 I ! ! ! ! ! I ! ! I ! I I I I I I I I I I I I I I I I ! ! ! ! I I I I I I I ! ! I I I I I I I ! ! ! ! I I I I I M I I I I I I 
I This is the go/no-go test which runs the major functional tests. I 

I I I 1 1 ! t i i t I I I I I I I I t I I i t i t t t I i t I 1 I I I I I I I t ! 1 1 1 I i i t I 1 ! t I I I I t i t j 1 1 1 1 I I t ! 



gfi clear 
connect clear 



'yes" 



CLEAR ALL GFI RECOMENDATIONS 
Clear all connect information. 



execute test_bus2 () 
execute test_rom2 () 
execute test_ram2 () 
execute test_pia2 () 
execute test_rs232b {) 
execute test_video2 () 

end program 
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FUNCTIONAL BLOCK TESTS FOR THE 
DEMO/TRAINER UUT DIAGNOSTIC PROGRAM 



6.5. 



Q 



This section contains the following functional test programs, 
which are necessary to support the diagnostic program for the 
Demo/Trainer UUT: 

test_bus2 Tests the Microprocessor Bus functional 

block. 

testj?ia2 Tests the Parallel I/O function block. 

testj-amZ Test the RAM functional block. 

test_rorn2 Tests the ROM function block. 

test_rs232b Tests the Serial I/O function block. 

test_yideo2 Tests the video circuitry (the Video 

Control, Video RAM, and Video Output 
functional blocks). 

These programs are much like the programs by the same name 
found in Section 4 and used in Section 5 of this manual. 
However, these programs also contain the necessary fault 
condition handlers and gfi hint commands to tell GFI where to 
start backtracing if the functional block fails. 



%0 
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program test bus2 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
FUNCTIONAL TEST of the Microprocessor Bus. 

This program tests the unbuffered microprocessor bus, performs an 
access at each decoded address of the buffered bus, and checks the 
data bus for bus contention (where a component outputs onto the data 
bus at incorrect times) . If bus contention is detected then the 
program TST_CONTEN is executed. TSTjCONTEN checks for incorrect 
enable line conditions on all the components on the buffered data bus. 



TEST PROGRAMS CALLED: 

tst_conten (addr, data_bits) 



Local Constants: 
ZERO_AT_ROM0 
ZER0_AT_R0M1 
IO_BYTE 
MEM_WORD 

Local Variables Modified 



i i i i i i t t i t t 

Declarations 
t t M M M n 



Test for bus contention on 
-the data bus by checking the 
enable lines of all devices 
on the data bus. 



Address of zero data in ROMO 
Address of zero data in R0M1 
I/O BYTE address specifier 
MEMORY WORD address specifier 



value returned from a read 

I!!!!!!!!!!!!!!!!!!!!!!!!!!! 



Main 
1111 



!!! 



declare numeric ZERO_AT_ROM0 
declare numeric ZERO AT R0M1 



$E002A ! Location in ROMO where exists 
$F0022 ! Location in R0M1 where exists 



! Setup Statements 

podsetup 'enable -ready' "on" 

podsetup 'report forcing* "on" 

I0_BYTE = getspace space "i/o", size "byte" 

MEM_W0RD = getspace space "memory", size "word" 

! Test the Unbuffered Microprocessor Bus. 

testbus addr 

! Test the Extended Microprocessor Bus and Address Decoding. 



setspace (MEM_WORD) 

read addr 

read addr $10000 

write addr $20000, data 

read addr $30000 

read addr $E0000 

read addr $F0000 

setspace (IO_BYTE) 

read addr 

read addr $2000 

read addr $4000 



! RAM BANK 

! RAM BANK 1 

! VIDEO RAM (write only) 

! INTERRUPT POLL 

! ROM BANK 

I ROM BANK 1 

! VIDEO SELECT 
! RS232 SELECT 
! PIA SELECT 
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! Test for Bus Contention driving lines low by accessing unused address space 



setspace (MEM_WORD) 
x = read addr $50000 
if x <> $FFFF then 

execute tst_conten ( $50000, cpl (x) and $FFFF) 

return 
end if 



SPARE-2 ADDRESS SPACE 



! Test for Bus Contention driving lines high by reading and writing RAM 
! If failure then check for bad RAM by reading zeros from 2 other devices. 



write addr 0, data 
x = read addr 

if x <> then ! 

if (read addr ZERO_AT_ROM0) <> then 
if (read addr ZERO_AT_ROMl) <> then 
execute tst_conten( 0, x) 
return 
end if 
end if 
end if 



! WRITE and READ RAM addr 

! If fails then check for bad RAM 

! by reading 0's at ROM0 and ROM1 



\^ t J 



end program 



6-19 



program test_pia2 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
FUNCTIONAL TEST of the PARALLEL I/O functional block. 

This program tests the PARALLEL I/O functional block of the 
Demo/Trainer. The two LEDs and the four pushbutton switches are 
tested. The test operator is prompted to visually inspect the LEDs 
as the LEDs count a series of numbers. 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



TEST FUNCTIONS CALLED: 
keys ( key_number ) 



leds 



(led_addr, led_name) 



If gfi has an accusation, 
display the accusation; 
otherwise create a gfi hint 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting) . 



Test Demo/Trainer pushbutton ! 
key keyjnumber. Prompt test 
operator to push the key. 

Test Demo/Trainer LED led_name 
which is driven by the PIA and 
has the address led addr. 



I ! I I I I M I ! 1 t I T T M I T 1 1 1 I t t M M M t t 1 I t M M M t 1 t t I t t ! t 



t i i t t : t t i i i i i i i t t 



r i i i i i i i t i i i t t t i i i i 



! I ! t 1 I I 



t t 1 1 1 1 I I I t 



I I I I I I 1 I 



! Main Declarations 

t t i 1 1 1 1 1 t i i t t t t t j i i t i t t t i 



t t t i t n t i t 



i i i i i i 1 1 



declare global numeric tlb 
declare global numeric tli 



! Terml buffered output & input 
! Terml unbuffered input 



? j j i t j i t i t t t t t t t i i i i ; ; ; ; ; j j i | t t i i i ; ; i it | j t t t i ; I j j i i i i !!!!!!!!!!!!!!!!!! M 
! FAULT CONDITION HANDLERS: ! 

! These fault conditions are generated by the this program. These ! 
! handlers perform isolation of the faulty circuit. The handlers ! 
! which isolate the LED problems perform a GFI test on the LED. ! 
! If all signals are good and the test operator has failed the LED, ! 
! then the LED is accused as a bad component. ! 

t t t t ; t t t t i i i t i i ; t t i t I t n t t t i t t i t t j m t t t i i i i i j m t t i i M! I! !!!!!!!! I !!!!!!! ! 

handle 'PIA LED A failed' 
declare global string rev 
declare string newline = "\nl" 

if gfi test "U32-1" fails then 

abort_test ("U32-1") 
else 

if gfi test "U33-1" fails then 

abort_test ("U33-1") 
else if gfi test "U33-13" fails then 

abort_test ("U33-13") 
else if gfi test "U33-10" fails then 

abort_test ("U33-10") 
else if gfi test "U33-8" fails then 

abort_test ("U33-8") 
else if gfi test "U33-7" fails then 

abort__test ("U33-7") 
else if gfi test "U33-2" fails then 

abort test ("U33-2") 
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else if gfi test "U33-11" fails then 

abort_test("U33-ll H ) 
else if gfi test "U33-6" fails then 

abort__test("U33-6") 

else 

print rev, newline, "LED A IS BAD", newline, "REPLACE LED A" 
end if 
end if 
end handle 

handle 'PIA LED B failed" 
declare global string rev 
declare string newline = "\nl" 

if gfi test "U46-1" fails then 

abort_test("U46-l") 
else 

if gfi test "U47-1" fails then 

abort_test("U47-l") 
else if gfi test "U47-13" fails then 

abort_test ("U47-13") 
else if gfi test "U47-10" fails then 

abort_test ("U47-10"} 
else if gfi test "U47-8" fails then 

abort_test ("U47-8") 
else if gfi test "U47-7" fails then 

abort_test ("U47-7") 
else if gfi test "U47-2" fails then 

abort_test("U47-2") 
else if gfi test "U47-11" fails then 

abort_test ("U47-11") 
else if gfi test "U47-6" fails then 

abort_test ("U47-6") 
else 

print rev, newline, "LED B IS BAD", newline, "REPLACE LED B" 
end if 
end if 
end handle 

handle *PIA KEY 1 failed' 

abort_test ("U31-14") 
end handle 

handle 'PIA KEY 2 failed' 

abortJ:est ("U31-15"} 
end handle 

handle 'PIA KEY 3 failed' 

abortjtest ("U31-16") 
end handle 

handle 'PIA KEY 4 failed' 

abortjtest ("U31-17") 
end handle 
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I!!!!!!!!!!!!!!!!!!!!!! I !!!!!!!!!! !! !!!!!!!!!!!!!!! !! ! !! !!!! I !!!!!!! !! !! J 
! Functions I 

t J t t t J t t t j i i i i i j j i ! t t t r t t t i t i i t t t i t t t i t i ] j j ' i i t i i j j i i t !!!!! !! !!!!!!!!! ■!! ! ! 

function keys (keynum) 

declare numeric keynum ! Number of key to test, 

declare string norm = "\lB£Om" ! Normal video escape string 

declare string rev = "\lB[0;7m" ! Reverse video escape string 

declare string entry 
declare string fail = **" 
declare global numeric tlb 
declare global numeric tli 

mask » setbit (keynum - 1) 

loop until fail = chr ($D) ! loop until YES key 

print on tlb ,"\nlPress ", rev," UUT KEY ", keynum," ",norm," pushbutton" 

print on tlb ,"Press any 9100 key if test is stuck" 

loop until (poll channel tli, event "input") = 1 
if ((read addr $4004) and mask) = then return 

end loop 

loop until (poll channel tli, event "input") = ! Flush input buffer 
input on tli , entry 

end loop 

print on tlb ,"\nlPress ",rev, " YES ",norm, " to fail KEY ", keynum," test," 

print on tlb , "Press "+rev+" NO * , +norm+" to continue key test," 

input on tli ,fail 
end loop 

print on tlb , "\nl\nl" 

fault ! Fail Key test (set termination 

end function ! status of function to fail. 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

function leds (led_addr, led_name) 
declare numeric led_addr 
declare string led_name 
declare string key 
declare string norm = "\lB[0m" 
declare string bold = "\lB[lm" 
declare string rev = "\lB[7m" 
declare string clear_screen = "\1B[2J" 
declare string no_auto_linefeed = "\lB[20h" 
declare global numeric tli 
declare numeric array [0:10] numbers 

numbers [0] = $C0 \ numbers [5] = $92 

numbers [1] » $F9 \ numbers [6] = $82 

numbers [2] = $A4 \ numbers [7] = $F8 

numbers [3] = $B0 \ numbers [8] = $80 

numbers [4] = $99 \ numbers [9] = $98 

NO = chr($7F) \ YES = chr ( $D) 

print norm, clearjscreen, "Watch LED ", led_name, " count" 

print "Press ", rev, " ENTER ", norm, " key to start LED counting." 

input key 

print clear_screen 

for i = to 9 

write addr led_addr, data numbers [i] 

wait time 500 
next 
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write addr led__addr, data $7F 

print clear_screen, "\1B[201" 

print "\lB[l;lfDid LED ", led_name, " display ALL segments off, then" 

print "\lB[2;lfdigits to 9, then only the Decimal Point ?" 

print "\lB[3;fpress: "+rev+" YES ,, +norm+" or "+rev+" NO "+norm 

loop until key = YES or key = NO 

input on tli ,key 

if key = NO then fault 
end loop 
write addr led_addr, data $FF \ print no__auto__linef eed, clearjscreen 

end function 

!!!!!!!!!!!!!!!!!!!!!!!!!! I !!!!!!!!!!!! I !!!!!!!!!!!!!!!!!! I I 1 !!!!!!!!!!! ! 
! PARALLEL I/O Test. ! 

I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

tlb = open device "/terml", as "update", mode "buffered" 
tli = open device "/terml", as "input", mode "unbuffered" 
execute pia^init 

if leds($4000, "A") fails then fault 'PIA LED A failed' \ return 
if leds($4002, "B") fails then fault 'PIA LED B failed' \ return 

if keys(l) fails then fault 'PIA KEY 1 failed' \ return 

if keys (2) fails then fault 'PIA KEY 2 failed' \ return 

if keys (3) fails then fault 'PIA KEY 3 failed' \ return 

if keys (4) fails then fault 'PIA KEY 4 failed' \ return 

end program 
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program test_ram2 

I 1 1 1 I I I I I I I I I ! ! ! ! ! ! I t t 1 I ! ! I I 1 1 1 I t 1 I I I I t t t M ! I I I I I t I t t I I I I t t I t t I I I I I I I ! I 



FUNCTIONAL TEST of the RAM functional block. 

This program tests the RAM functional block of the Demo/Trainer. The 
TL/1 testramfast command is used to test the RAMs. If the RAMs are 
found to be faulty, then one of twelve built-in fault conditions is 
generated. 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



If gfi has an accusation, 
display the accusation; 
otherwise create a gfi hint 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting) . 
t t i i i i i i i i i i i i i i i i i t i t t t t t t i t t t t t i ! i t t t i i i i i t t i i i i i i i it i ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! FAULT CONDITION HANDLERS: ! 

! Built-in testramfast fault condition handlers ! 

i j it 1 1 i i i i i i t r t t t t t i t t t t t i i t 1 1 1 1 t t i t i i i 1 1 1 1 i i i i i i 1 1 1 1 t i t t i t t 1 1 1 t i t t t t t i i i 



handle ram_addr_fault (data_mask) 

declare numeric data__mask 

declare string clear_screen » "\1B[2J" 

print clearjscreen 

print "XnlRAM addr line fault detected, CONTINUING" 

fault ram__component data_bits data_mask 
end handle 

handle ram_addr__addr_tied (data_mask) 

declare numeric data_mask 

declare string clearjscreen = "\1B[2J" 

print clear_screen 

print "\nlRAM addr lines tied detected, CONTINUING" 

fault ram_component data_bits data_mask 
end handle 



m 



handle ram_addr_data_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clear_screen = "\1B[2J" 

print clearjscreen 

print "XnlRAM addr-data tied detected, CONTINUING" 

fault ram_component data_bits (data xor data__expected) 
end handle 

handle ram_addr_data__tied_unconfirmed (data_expected, data) 

declare numeric data__expected 

declare numeric data 

declare string clearjscreen = "\1B[2J" 

print clear_screen 

print "\nlRAM addr-data tied detected, CONTINUING" 

fault ram_component data__bits (data xor data_expected) 
end handle 
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f^ 



handle ram_data_data_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clearjscreen = H \1B[2J" 

print clearjscreen 

print "\nlRAM data lines tied detected, CONTINUING" 

fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_data_fault (data) 

declare numeric data 

declare string clear_screen = M \1B[2J" 

print clear_screen 

print "\nlRAM data line fault detected, CONTINUING" 

fault ram_component data_bits data 
end handle 

handle ram_data_incorrect (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clearjscreen = "\1B[2J" 

print clearjscreen 

print "\nlBAD RAM data detected, CONTINUING" 

fault ram_component datajoits (data xor data_expected) 
end handle 

handle ram_data_high_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clear_screen = "\1B[2J" 

print clear_screen 

print "\nlRAM data tied high detected, CONTINUING" 

fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_data_low_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clearjscreen = "\1B[2J" 

print clearjscreen 

print "\nlRAM data tied low detected, CONTINUING" 

fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_cell_cell_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clear_screen = "\1B[2J" 

print clear_screen 

print "\nlRAM cells tied detected, CONTINUING" 

fault ram_component data_bits (data xor data_expected) 
end handle 

handle ram_cell_low_tied (data_expected, data) 

declare numeric data_expected 

declare numeric data 

declare string clearjscreen = "\1B[2J" 

print clear_screen 

print H \nlRAM cell tied low detected, CONTINUING" 

fault ram_component data_bits (data xor data_expected) 
end handle 
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Redirected fault handler 



The RAM block can fail if a problem exists with the ready circuit. ! 
So test the ready circuit, then if the ready circuit is good, use < 
the data bits parameter passed from the testramfast built-in fault ! 
handlers to test the failing RAM IC. If the RAM IC is good then 
test the data bus at the bus buffers. (Testing the data bus buffer 
will detect any problem in the data bus) . 
i I t j tt j t j t j j ; ; ; j i i i t t t t t t j j ; j ; j i t j I i I j I t t t !!!!!! I I I !! I !!!!!!!!! ! I M III I 



handle ram_component (datajoits) 
declare numeric data_bits 
declare string array [0:$15] ram_ic 



ram ic[0] = "U55" 


\ 


ram ic[l] 


= 


»U54" 


ram ic[2] = "U53" 


\ 


ram ic[3] 


= 


"U52" 


ram ic[4] - "U51" 


\ 


ram ic[5] 


= 


"U50" 


ram ic[6] = "U49" 


\ 


ram ic[7] 


= 


"U48" 


ram ic[8] = »*U41" 


\ 


ram ic[9] 


= 


"U40" 


ram ic[10] = "U39" 


\ 


ram ic[ll] 


= 


"U38" 


ram ic[12] = "U37" 


\ 


ram ic[13] 


= 


"U36" 


ram ic[14] = "U35" 


\ 


ram ic[15] 


= 


"U34" 



RAMs 


U55, 


U54 


RAMs 


U53, 


U52 


RAMs 


U51, 


U50 


RAMs 


U49, 


U48 


RAMs 


U41, 


U40 


RAMS 


U39, 


U38 


RAMs 


U37, 


U36 


RAMs 


U35, 


U34 



! If ready circuit is untested, then check Ready circuit 

if (gfi status "Ul-4") = "untested" then 

if gfi test "Ul-4" fails then abort_test ("Ul-4" ) 
end if 

! Check highest order ram that is failing, using ram_ic array to get refname. 

if data_bits <> then 

bad_ram_ref = ram_ic[msb(data_bits) ] + "-1" 

if gfi test bad_ram_ref fails then abort_test (bad_ram_ref) 

end if 

! Check Data Bus buffers. 

if gfi test "U3-2" fails then abort_test ("U3-2" ) 
if gfi test "U23-2" fails then abort_test ("U23-2") 
end handle 

I J ; J ; i t t 1 I I 1 t J ! M I J I t t t ; ; j j j J I I i i t t j j ; j ; j i ! j t t j ; j j ; i t j j j i j t j i i t I j i i i i t t i t 
! FUNCTIONAL TEST PROGRAM to test RAM CIRCUIT FUNCTIONAL BLOCKS. ! 

I I I I I I J J J J t I I I I I 1 ! T M ! t t t t J J I ; I 1 I I J J I I I J I J I 1 M J J J J I I 1 t I I J J J J ; I M t I ; J J J J J J 

! Setup 

podsetup 'enable -ready' "on" 

podsetup 'report forcing' "on" 

setspace space (getspace space "memory", size "word") 

! Main part of test 

testramfast addr 0, upto $1FFFE, delay 250, seed 1 

end program 
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program test rom2 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! in n J t 
FUNCTIONAL TEST of the ROM functional block. 

This program tests the ROM functional block of the Demo/Trainer. The 
TL/1 testromfull command is used to test the ROMs. If the ROMs are 
found to be faulty, then one of seven built-in fault conditions is 
generated. 

TEST PROGRAMS CALLED: 

abort_test (ref-pin) if gfi has an accusation, 

display the accusation; 
otherwise create a gfi hint 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting) . 
!! !! !!!!!!!!!!!!!!!!! M !!!!!!!!!! !! !! I MM! I !! MM !! !!!!!!!! I! .'!!!!!!! ! 

!!!!!!!!M!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!|!!!!!!!!!!!!!!|!! 
FAULT CONDITION HANDLERS: 

Built-in testromfull fault condition handlers 
!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! . 

handle rom_sig_in correct (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J" 

print clearjscreen 

print "\nlBAD signature detected, CONTINUING" 

fault rom_component addrjoits addr 
end handle 

handle rom_addr_fault (addr) 

declare numeric addr 

declare string clear_screen => "\1B[2J" 

print clear_screen 

print M \nlRom address line fault detected, CONTINUING" 

fault rom_component addr_bits addr 
end handle 



handle rom_addr_addr_tied (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J" 

print clear_screen 

print M \nlRom address line tied detected, CONTINUING" 

fault rom_component addr_bits addr 
end handle 

handle rom_data_high_tied_all (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J" 

print clearjscreen 

print "\nlRom data all high detected, CONTINUING" 

fault rom_component addr_bits addr 
end handle 






handle roni_data_low_tied_all (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J" 

print clearjscreen 

print "\nlRom data all low detected, CONTINUING" 

fault rom_component addr_bits addr 
end handle 
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handle rom_data_fault (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J" 

print clear_screen 

print "\nlRom data line fault detected, CONTINUING" 

fault rom_component addrjsits addr 
end handle 

handle rom_data_data_tied (addr) 

declare numeric addr 

declare string clear_screen = "\1B[2J M 

print clear_screen 

print "\nlRom data lines tied detected, CONTINUING" 

fault rom_component addrjoits addr 
end handle 



n m m j j m n n m I m j j n |! !! n ! i nn! m !!!!!!! i Ml!!!!!!!!!!!!!!! N H H ! 
Redirected fault condition handler: 

Use failing address bits parameter passed from testromfull fault 
condition handlers to gfi test the ROM bank that failed. 
I!!!!!!!!!!!!! II I I !! ! I !!!!! !! !! I !! I !! !! I !!!!!!!!!!!!!!! I !!!!!!!!!!!! I ! ! 



handle rom__component (addr_bits) 
declare numeric addr bits 



if addr_bits >= $F0000 then 

if gfi test "U27-1" fails then abort_test ("U27-11") \ return 
if gfi test "U28-1" fails then abort_test ("U28-11") \ return 

else 

if gfi test "U29-1" fails then abort__test ("U29-11") \ return 
if gfi test "U30-1" fails then abort_test {"U30-11") \ return 

end if 
end handle 



n 



j i i i i i i i t t i i j i i t i i i i m i t j t i i j i i j t j j i !!!!!! I !!!!!!!! !! !! !! !!!!!!! H !!!! ! 
FUNCTIONAL TEST PROGRAM to test ROM CIRCUIT FUNCTIONAL BLOCK 
t t j i t i t t i t j i it t i t i t i i i i i t t j j i t it i j i i j i t t t it i ] j j t i t i i j | i i t t i i i i i j j t t t it i 



! Setup. 

podsetup 'enable -ready" "on" 

podsetup 'report forcing* "on" 

setspace space (getspace space "memory", size "word") 

! Main part of Test. 

testromfull addr $FO000, upto $FFFFE, addrstep 2, sig $156F 
testromfull addr $E0000, upto $EFFFE, addrstep 2, sig $B61E 

end program 
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program test_rs232b 



! I! !!!!!!!!!!!!!!!! I! !!!!!!!!! I! !!!!!!! M !!!! I !!! U ! I I M !!! I !!!!!!!!!! ! 
FUNCTIONAL TEST of the SERIAL I/O functional block. 

This program tests the SERIAL I/O functional block of the Demo/ 
Trainer. The two RS-232 ports are tested by setting three Dip 
Switches to loop back the two ports (SW4-4, SW4-5 and SW6-4 loop back 
ports A and B) . The SERIAL I/O functional block also outputs two 
interrupt request signals. This program also checks the interrupt 
circuitry. 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



frc int 



rd cscd 



FUNCTIONS CALLED: 

syncjouffer (address, data) 



Call fail for reference name 
then if gfi has an accusation 
display the accusation else 
create a gfi hint for the 
ref-pin and terminate the test 
program (GFI begins trouble- 
shooting) . 

POD PROGRAM forces repetitive 
interrupt acknowledge cycles 
and returns first interrupt 
vector found on data bus. 

POD PROGRAM returns the 24 bit 
interrupt cascade address that 
was found on the address bus 
during the last interrupt 
acknowledge cycle. 

POD PROGRAM returns the most 
recent interrupt vector and 
rearms the pod to respond to 
the next interrupt. 



Synchronize FIFO buffer in 
DUART to be last byte received 
Receive buffer is located at 
the value of address. The 
data in data is written to the 
DUART and then read until it 
appears in the FIFO or count 
expires. 



MM 

Main 
i t i i 



!!!!!!!!!!!! 

t I I 1 I t M J J It 

Declarations 
i t i i i i i i t i t t 



ittimi 



t M t t t M t 



t M I II t 11 



declare 

string q 
string rev 
string norm 

end declare 



"\lB[0;7m M 

w \lB[Qm" 



! used to get input from keyboard 
! Reverse Video escape sequence 
! Normal Video escape sequence 
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!!!!!!!!!!!!!!!!!! MM !! !!!!!!!!! !! !!!! !! ! ! ! ! !!!!!!!!!!!!! !! !!!!!!!!!!! M 
! FAULT HANDLERS: ! 

! These fault conditions are generated by the this program. These ! 
! handlers verify the failure using the Probe or I/O Module and ! 
! then pass control to GFI. ! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

handle 'RS232 Port A failed' 

if gfi test "Ull-35" fails then abort_test {"Ull-35") 
end handle 

handle 'RS232 Port B failed' 

if gfi test "Ull-5" fails then abort_test ("Ull-5") 

if gfi test "Ull-11" fails then abort_test ("Ull-11") 
end handle 

handle 'Interrupt failed' 

if gfi test "U10-2" fails then abort_test ("U10-2") 

if gfi test "U20-9" fails then abort_test ("U20-9") 
end handle 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
! FUNCTIONS ! 

t t t t t t i i i i i i t i t i i i I ; I ; i i ; j it t t i t i i t t i t it t t i i i i t it t i i t t t t t i i i i i i i i i t t t i i t i 

function sync_buffer( address, data ) 
declare numeric address 
declare numeric data 

! Synchronize FIFO buffer in DUART. Write and then read until correct data 
! is returned or count has expired. 



write addr address, data data 

wait time $200 

cnt = \ x = 

loop until x = data or cnt > 3 

x = read addr address 

cnt = cnt + 1 
end loop 
end function 



Transmit Data 31 on port A 



!!!!!!!!!!!! i !!!!!!!!!!!!!!!!!!! N !!!!!!! !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! 
! FUNCTIONAL TEST of the SERIAL I/O Functional Block. ! 



i i i i i i t t m t t i i i i i i t t i i i i i i t i i t t t t t i m t i i i i i i t t J t i ] i t t i i i i i t t t i t i i i i t i j i t i 



! Set interrupt acknowledge cycles on and use the 80286 
! pod specific programs rd_rearm(), frc_int() & rd__cscd(). 

podsetup 'report intr' "off" 

podsetup 'intr_ack on' I Enable Interrupt Ack. cycles 

option = getspace space "i/o", size "byte" 

setspace (option) 

execute check_loop() 

execute rd rearm () ! Clear interrupts 
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! Main part of Test. Verify DUART port A. 

sync_buffer( $2006, $61 ) ! Synchronize FIFO in DUART for port A 

write addr $2006, data $55 ! Transmit Data 31 on port A 

wait time $200 

if ((read addr $2002) and $F} <> $D then fault 'RS232 Port A failed' \ return 

if (read addr $2006) <> $55 then fault 'RS232 Port A failed' \ return 

write addr $2006, data $55 ! Transmit Data 31 on port A 

wait time $200 

if ((read addr $2002) and $F) <> $D then fault 'RS232 Port A failed' \ return 

if (read addr $2006) <> $55 then fault 'RS232 Port A failed* \ return 

! Verify DUART port B and interrupts. 

sync_buffer( $2016, $61 ) ! Synchronize FIFO in DUART for port B 

write addr $201E, data $FF ! set output port low 

write addr $2016, data $31 ! Transmit Data 31 on port B 

if frc_int() <> $22 then fault 'Interrupt failed' \ return 

if rd_cscd() <> $2016 then fault 'Interrupt failed' \ return 

if (readstatusO and 8) <> 8 then fault 'Interrupt failed' \ return 

if (read addr $2016) <> $31 then fault 'RS232 Port B failed' \ return 

if frc_int() <> $27 then fault 'Interrupt failed' \ return 

write addr $201C, data $FF 

if ((read addr $201A) and 2) <> then fault 'RS232 Port B failed' \ return 

end program 
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program test_video2 



t i I i i i i I j J j j i r i t t t i i i i i i t t t I t i i t i ! I !!!!!!!!!! ! ! ! !!!!!!!!!!!! !! !!!!!!!!! ! 
FUNCTIONAL TEST of the VIDEO functional block ! 

\ 
This program tests the VIDEO functional block of the Demo/Trainer. ! 
The video test uses the gfi test command to run stimulus programs and 
to check the outputs of the Video circuit against the stimulus program 
response files. The gfi test command returns a passes status if all 
the measured results from running the stimulus programs match the 
response files. Otherwise the gfi test command returns a fails 
status. 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



tst_vidctl () 



If gfi has an accusation, 
display the accusation; 
otherwise create a gfi hint ! 
for the ref-pin and terminate 
the test program (GFI begins 
troubleshooting) . 

Test program to test the video 
control functional block 
outputs. Returns passes 
termination status if ! 
functional block is good else ! 
return fails termination 
status. 



tst_vidram () Test program to test the video 

RAM functional block outputs. 
Returns passes termination 
status if functional block is 
good else return fails 
termination status. 

! ! ! ! ! ! I I ! ! ! t t 1 t 1 t I t I I I t ! ! I ! 1 I t 1 t I t t t t t t t I I I I t I I I I ! I I I t I t I I I I I t t 1 I t I ! ! ! 1 



!!!!!!!!!!!!!!!!!!! I !!!!! I !!!!!!!!!!!!! H !!!!!!!!!!!!!!!!!!! I !!!!!!!!!!! ! 
! FAULT CONDITION HANDLERS: ! 

! These fault conditions are generated by the this program. These ! 
! handlers isolate the failure in the video circuit to the Video ! 
! control section, Video RAM section or the Video output section. ! 
! Once the failing Video subsection has been identified, then GFI ! 
! is started. I 

i mm mi t ! 1! !!!!!!!!!!!!!!!!!!!!!!!!!!!! M !!!!!! I !!!!!!! I !!!!!!! H !!!!! !! 

handle video__output 

! IF Video Control section is bad, tst_vidctl will start GFI. 

if tst_vidctl() fails then return 

! IF Video RAM section is bad, tst_vidram will start GFI. 

if tst_vidram() fails then return 

! Video Control and Video RAM have passed. Video Out is bad. Start GFI. 

abort_test (" J3-9") 
end handle 
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handle video_scan 

gfi hint "J3-8" 

gfi hint "J3-9" 

fault 'gfi hints generated' ' please run gfi 
end handle 

i i i i i i i i i ; i I j j t t t t t j i i i i j j i t t t i i i ; j j i t r i ; ; t t t i i ; i t i I f it i i i t t i i I i j i i t t i i i i 

! FUNCTIONAL TEST of the VIDEO Functional Block. ! 

!!!!! I I I I !!!!!!!!!!!! I !!!!!!!!!! I !!!! I !!!!!!!!! I !!!!!!!! MM M !!!!!!!!!! ! 

! Setup and initialization, 

connect clear "yes" 

podsetup 'enable -ready' "on" 

print "\nl\nl" 

! Main part of Test. 

if gfi test "J3-8" fails then fault videojscan \ return 
if gfi test "J3-9" fails then fault videojscan \ return 

if gfi test "U78-11" fails then fault video_scan \ return 
if gfi test "U78-28" fails then fault videojoutput \ return 
if gfi test "U78-29" fails then fault video_output \ return 
if gfi test "J3-7" fails then fault video_output \ return 

end program 
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Section 7 

Troubleshooting 



After a failing functional block is isolated with a diagnostic 
program, Unguided Fault Isolation (UFI) or Guided Fault 
Isolation (GFI) troubleshooting can be used to backtrace to the 
bad node or component. 



UNGUIDED FAULT ISOLATION (UFI) 7.1. 

UFI troubleshooting is valuable when you need experience with 
stimulus programs before expanding to the GFI environment. It 
lets you use stimulus programs to determine whether a node is 
good or bad, without having to enter a node list for the UUT. 

UFI is used in a manner similar to GFI: the GFI key on the 
operator's keypad begins the process. Unlike GFI, UFI is 
designed to test only output pins. When testing with the probe, 
the output source for a node can be characterized and the other 
points on the node (such as inputs) can be probed looking for 
the same response. However, when testing with the I/O 
module, only the output pins can be measured because the other 
pins on the node are connected to I/O module pins different from 
the pins UFI thinks it should be measuring. 

When an operator needs to troubleshoot boards before the GFI 
database is developed, he can use stimulus programs in UFI 
mode while waiting for GFI to be completed. However, he 
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needs to understand the UUT since UFI does not recommend 
the next location to test 



GUIDED FAULT ISOLATION (GFI) 7.2. 

The 9100A/9105A's built-in GFI algorithm guides an operator 
in diagnosing a faulty circuit to the component or node level 
without assistance from a skilled technician. 

Once a functional test or larger diagnostic program has generated 
a list of suspect nodes, GFI troubleshooting can begin. The 
GFI key on the operator's keypad starts the process. GFI 
begins with a bad output and tests the suspect node. Nodes are 
exercised with a stimulus program and determined to be good or 
bad by comparing their measured response to responses learned 
from a known-good UUT. 

When a node is bad, GFI tests the inputs which affect that node 
and recommends which node to test next. If the output of a 
component is bad and all inputs to the component are good, GFI 
accuses the component of being bad or the output node of being 
loaded. The node may be shorted to another node or a defective 
component may be loading the node. If an input is bad and the 
output source for that node is good, GFI accuses the node of 
having an open circuit 

The GFI capability is general enough to troubleshoot most 
digital circuits. To apply GFI to a particular UUT, however, 
you will need to supply UUT- specific information to the GFI 
database for that UUT. The files used for this database are 
summarized in Section 7.5 of this manual and described fully in 
the Guided Fault Isolation section of the Programmer's Manual. 



STIMULUS PROGRAMS 7.3. 

Stimulus programs are TL/1 programs used by GFI or UFI to 
exercise UUT nodes in such a way that responses at the nodes 
can be analyzed and compared to responses of nodes on a 
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known-good UUT. A typical stimulus program consists of up 
to 6 main parts: 

1. (As required) - Initialize the UUT and define the 
measurement device. 

2. (As required) - Setup of the pod, probe, or I/O 
module. 

3. Use the arm command to start the measurement of 
the node response. 

4. Use any commands necessary to apply the stimulus. 

5 . Use the readout command to end the measurement of 
the node response. 

6. (As required) - Restore any conditions altered by the 
setup step above (step 2). 

Stimulus programs should satisfy three very important criteria: 

• The program must be independent, initializing the UUT as 
required. This is because GFI can begin backtracing at 
any node, and the state of the UUT, prior to running the 
stimulus, is unknown. The program must also restore 
any adjustments it makes to the calibration offset. 

• During stimulus execution, only one pin should drive a 
node: that is, during the period between the arm and 
readout commands, one and only one pin should be a node 
signal source (data should flow in only one direction). 

• There should be at least one stimulus program for each 
output to the node. 

See the "Stimulus Programs" section in the Programmer's 
Manual for more detailed information on stimulus programs. 



o 
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STIMULUS PROGRAM RESPONSES 7.4. 

Both UFI and GFI select the appropriate stimulus programs to 
exercise a node to be measured and compare the actual response 
at the node with a stored response from a known-good UUT. 
These responses may be any of the following (or combinations 
of them): 

CRC Signature. 
Transition Count. 
Frequency. 

Asynchronous Level History. 
Synchronous Level History. 

The information below summarizes each of these response 
measurements. See the Guided Fault Isolation section of the 
Programmer's Manual for more complete information. 



Learning Responses From a 

Known-Good UUT 7.4.1. 

The 9100A editor's LEARN function is used to learn a set of 
responses measured on known-good UUT nodes. Once a 
stimulus program is written to exercise a node, a response file 
can be generated. To do this, the 9 100 A is commanded to learn 
responses at a node or set of nodes and the system prompts the 
operator to connect the measurement device (probe or I/O 
module) to the component providing the node signal source. 
The 9100A makes a series of measurements and determines the 
characteristics. It learns the response with three measurements 
(early, normal, and late clock or sync events) to make sure the 
response is stable and that the measurement can be used as a 
reliable characterization of that node. 

Node characterization may use one or more of five 
characteristics to determine whether the node is good or bad. 
You can select which of the five should be saved in a response 
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file. GFI and UFI use these saved characteristics to determine 
whether a node is good or bad. 



CRC Signatures 7.4.2, 

It is very important to ensure that a CRC signature used in node 
characterization will properly identify all good UUTs, at all 
measurement temperatures and power supply levels. A marginal 
signature occurs when the measured node changes state near the 
clock transition or when the Start, Stop, or Clock signals are not 
stable. A marginal signature may appear stable on one UUT and 
thereby lead to a false sense of security. Other UUTs may yield 
different signatures because of temperature or power supply 
variations. 

When the 9100A editor learns a signature, it attempts to identify 
marginal CRCs by collecting signatures with advanced clock 
edges, normal clock edges, and delayed clock edges. If a 
signature has the same value for advanced and normal clock 
edges, it will be suffixed by a "-" sign. If a signature has the 
same value for normal and delayed clock edges, it will be 
suffixed by a "+" sign. If all three values agree, the signature is 
displayed with no qualification. 

A variable signature results if the Start, Stop, or Enable signals 
are irregular, compared to the Clock signal. In addition, since 
the Start, Stop, and Clock signals are edge-triggered, unstable 
signatures will result if the Start or Stop signal edge occurs at the 
same time as the Clock signal edge. 

Figure 7-1 shows how to test whether the start/stop interval is 
stable. Connect the Clock to the clock signal you want to use. 
Connect the probe or I/O module to a logic-high level and 
connect the Start and Stop lines to the locations where you 
would connect these lines when making the signature 
measurement. If the start/stop interval is stable, a constant 
number of clocks will occur between the start and stop 
condition, and the signature will be constant. If the CRC 
signature is not constant, the start/stop interval is unstable. 



j^\ 



7-5 



Start 
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Stop 
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Start/Stop 
Interval 



Clock 
(On Falling Edge) 



Data 
(Logic High) 




Figure 7-1 : Testing for Start and Stop Stability 
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Unstable signatures may also be caused by Start or Stop signal 
edges which occur at the same time as the Clock signal edge or 
by Start or Stop signals which are asynchronous to the selected 
clock signal Use an oscilloscope to determine whether a line is 
irregular or whether a timing problem exists between the Clock 
signal and the Start or Stop signal. 

If unstable signatures are caused by Start or Stop signal edges 
which occur at the same time as the Clock signal edge, select the 
other Clock edge (+ or -) and use the getoffset and setoff set 
TL/1 commands to adjust the measurement timing. 



Other Characterizations 7.4.3. 

Some circuits are difficult to characterize by a CRC signature. 
The node may have regular activity but there might be no signal 
which can be used as a clock to gather a consistent signature. In 
many such cases, nodes can be characterized by using transition 
counts. 

The transition count works on asynchronous signals. The 
transition count can monitor information that the CRC will not 
detect, such as extra transitions between CRC clocks. The 
transition count will typically be a range of counts, defined by a 
minimum and maximum, that represents the extremes of the 
three measurements taken by the LEARN function. Only low- 
to-high transitions are counted (not high-to-low). When the 
measurement is synchronized to the external lines, the data input 
is gated with the enable line, if used. A count of zero will result 
if the enable-true window does not overlap the low-to-high 
transition of the data. 

The frequency of a signal may be more important than its CRC 
or transition count. This is especially true for system clocks. If 
a system clock is run at 4 MHz rather than 8 MHz, everything 
on the board could appear to be good. However, when the 
board is plugged into a system, the board running at 4 MHz may 
cause a system failure. Frequency is also important for video 
signals such as horizontal and vertical sync. 
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Level history is an important characterization parameter when 
combined with signatures or transition counts. If a faulty node 
has the correct timing but swings between ground and an invalid 
level for part of the time, measuring asynchronous level history 
would detect this fault, which will be missed if only a CRC is 
measured. 

Consider the case where a node that should go high and low is 
stuck on a faulty UUT. Using both CRC and asynchronous 
level history to characterize the node will provide more complete 
information to the technician who repairs the board. The 
operator can see that the line is stuck when it should be 
changing. 

Level history can be used to detect glitches. If the measurement 
period is set so that a signal is either high or low during 
measurement, with no glitches, the level history will show only 
high or low. If the level history shows both high and low, a 
glitch has occurred. 



Calibration of the I/O Module and Probe 7.4.4. 

Whenever the pod performs a microprocessor operation, it 
generates a synchronization pulse which the 9100A/9105A uses 
to measure signatures and clocked levels. The synchronization 
pulse can be generated by several devices, including the pod or 
an external clock. 

In order for the system to measure critical signals reliably, each 
measurement device (I/O modules and probe) must be calibrated 
to this synchronization pulse on the system where it will be 
used, since each measurement device contains its own 
electronics that affect timing. If your tests must be accurate to 
within a few tens of nanoseconds on signal edges, calibration 
should be done. 

The procedures for calibration are given in the Technical User's 
Manual Calibration should be performed for each measurement 
device and for each synchronization mode of that device on the 
particular 9100A/9105A system where it will be used. For 
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example, the probe for an 80286-based UUT should be 
calibrated to EXT, POD ADDR and POD DATA on the 
9100A/9105A where the probe will be used. 

Calibration is UUT-dependent. For this reason, calibration 
settings should be saved under the specific directory for that 
UUT. If calibration is not performed, default calibration values 
will be used. These default calibration values will only work 
properly in some UUTs (those which have ample timing margin 
or which operate at slow speeds). 



Adjusting Sync Timing 7.4.5. 

The sync pulse that the measurement devices (I/O modules and 
probe) receive from the 9100A/9105A comes either from the pod 
or an external clock signal. The pod may provide sync pulses 
with different timings relative to microprocessor read/write 
operations, depending on the synchronization mode of the pod. 
For example, the 80286 pod has POD ADDR and POD DATA 
sync modes. The sync pulse in POD ADDR mode is earlier than 
in the POD DATA mode. See the timing diagram in the pod 
manual for the pod you are using. 

Most signals on a UUT can be characterized using the external 
or pod sync mode. However, in some cases, the sync pulse 
occurs at a different time than when the signal should be 
measured. 

The getoffset and setoffset TL/1 commands can be used to adjust 
the time when a signature or clocked level measurement is made, 
relative to the sync pulse. Figure 7-2 shows how this offset is 
implemented in the probe or the I/O module. The data to be 
measured passes through one delay line and the sync pulse 
passes through a different delay line. One of the delay lines is 
variable. By adjusting the variable delay line, the data is 
measured at a different time relative to the sync pulse. 

Section 3 of the TL/1 Reference Manual contains details about 
the getoffset and setoffset commands, including the 
approximate timing resolutions of the probe and the I/O module. 
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Figure 7-2: Synchronization-Pulse Delay Mechanism 
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Appendices C and E of the Technical User's Manual contain 
additional timing specifications for the pod, probe, and I/O 
modules. The Supplemental Pod Information for 9100AI9105A 
Users manual and the pod manuals have more detailed 
information about pods. 

When a program adjusts the sync timing, the original timing 
should be restored at the end of the program. This can be done 
by storing the result of a getoffset command, adjusting the 
timing with setojfset, and readjusting the timing with setoff set at 
the end of the program with the stored getoffset value. 

Dynamic RAM circuits usually require sync timing adjustment in 
order to measure the RAS and CAS signals, which do not 
necessarily coincide with the POD ADDR or POD DATA sync 
pulses. The Demo/Trainer UUT stimulus programs for the 
Dynamic RAM Timing functional block show one way to adjust 
the sync timing. 



THE UUT DESCRIPTION 7.5. 

The UUT description, which provides the 9100A/9105A with 
information used for GFI and UFI, consists of: 

• Reference designator list (reflist). 

• Part Library (part descriptions). A basic part library is 
provided with the system. 

• Node list (net list or wire list). 

The Programmer's Manual provides detailed information about 
this database and how GFI and UFI use it. The following 
sections are simply a brief overview. 



Reference Designator List (REFLIST) 7.5.1 . 

The reference designator list establishes the relationship between 
reference designators (such as M U80 M ) and a part or component 
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type (such as 7410). It also specifies the testing device (probe 
or I/O module) to be used on the component. 

A sample Demo/Trainer UUT reference designator list is shown 
in Appendix A. GFI and UFI both require the reference 
designator list to determine the device needed to test a 
component. 

No distinction is made between families of components, such as 
74LS00 or 74HCT00. The Fluke- supplied part library uses 
generic names like 7400 and 7432, so when you make entries in 
a reference designator list you will need to use generic names. 



Part Library (Part Descriptions) 7.5-2. 

The part library is a group of files (part descriptions) that 
describe UUT components. A part description specifies each 
pin to be an input, output, bidirectional, ground, power, or 
unused. Each output has a list of related inputs which affect that 
output. The library can be accessed through any UUT directory. 
A basic part library is supplied by Fluke. You can add part des- 
criptions, including custom designs. 

See the Guided Fault Isolation section of the Programmer's 
Manual for examples of part descriptions. 



Node List (Net List or Wire List) 7.5.3. 

The node list specifies interconnections between reference 
designators. The list is only necessary for GFI, which uses it to 
backtrace between components. 

A complete node list contains one line for each node in a UUT. 
The pins on one line are all connected to form a node. Lines 
may be continued on the next line with the backslash (\) 
character. 
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Appendix B contains a node list for the Demo/Trainer UUT. 
Reviewing this example will be helpful to you when developing 
you own node lists. 



Bus-Master Pins in a Node List 



7.5.4. 
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The 9 100 A normally determines the flow of data from the node 
list; it assumes that data can be sent from any pin to any other 
pin on a given node. However, sometimes two pins are 
connected together by a node but do not actually communicate 
with each other; this situation commonly arises in bus-oriented 
systems with many components connected to a common 
microprocessor data bus. 

In such cases, you need to let GFI know that only some pins 
(called bus-master pins) can communicate with all the other pins 
on the same node. This is done by entries in the optional 
^masters section of the node list. 

The ^masters section is optional, and for most UUT node lists it 
can be omitted. Where it is needed, it usually contains just a 
short list of pins, because most nodes have only a single source. 
It is only for nets such as the one in the following example that 
the ^masters section becomes important. 

Consider the node shown below: It consists of bit of a 
bidirectional data bus connecting several components to a 
microprocessor. 
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Only pin U25-15 can talk to all other input pins on the node and 
only U25-15 can receive from all other output pins on the node. 
Either condition would be sufficient to make U25-15 a bus- 
master pin. 

For this reason, pin U25-15 is shown as a bus-master pin in the 
partial node list below. It is listed in the regular section of the 
node list and is also included in the optional ^masters section of 
the node list. 



U8-12 U3-9 U42-21 

U25-15 U19-8 U22-2 U9-10 U31-11 

U17-4 U28-5 U27-6 



^masters 
U25-15 



See the Node List section in the Programmer's Manual for more 
information about bus-master pins. 



Choice of Backtracking Path 7-5.5. 

If there are two or more stimulus programs available for a node, 
GFI will attempt to use the program that stimulates all of the 
node f s outputs (and related inputs) before using programs that 
stimulate only some of the node's pins. 

Here are three cases that relate to the AND gate in Figure 7-3. 
Each case shows the test results from two stimulus programs, A 
and B, and the conclusion that GFI comes to: 
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Figure 7-3: Direction-Control Example 
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Case 1 : Input 1 Input 2 Output 3 

Stimulus Program A good good bad 

Stimulus Program B - bad bad 

GFI will accuse the node of being bad because stimulus 
program A covers all the nodes and is therefore evaluated 
first. In this case stimulus program B will not be 
executed. 

Case 2: Input I Input 2 Output 3 

Stimulus Program A bad good bad 

Stimulus Program B - bad bad 

GFI will test the component connected to input 1, again 
because stimulus program A covers all the nodes and is 
therefore evaluated first Therefore, GFI will backtrace to 
the Bus Buffer. 

Case 3: Input I Input 2 Output 3 

Stimulus Program A good good good 

Stimulus Program B - bad bad 

GFI will test the component connected to input 2, because 
stimulus program A finds no problem and the system goes 
on to evaluate stimulus program B. Therefore, GFI will 
backtrace to the DMA circuit. 

Consider these two problems in Figure 7-3, in which both the 
microprocessor and the DMA controller are both ^master 
components: 

• If the problem is in the microprocessor, evaluation is the 
same as for Case 2, above, and GFI troubleshooting traces 
back to the microprocessor from input 1 of the AND gate. 

• If the problem is in the DMA controller, evaluation is the 
same as for Case 3, above, and GFI troubleshooting traces 
back to the DMA circuit from input 2 of the AND gate. 
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While you can effectively steer GFI by designing stimulus 
programs to cover all or only some inputs and outputs, you do 
not usually need to worry about control of the backtracing path; 
it is only needed in special circumstances. 

Normally, you should design stimulus programs that test all 
inputs and outputs of a node or component. If there is no single 
stimulus program that covers all inputs and outputs, the 
9100A/9105A uses these criteria to determine status: 

• If ANY stimulus program gives a BAD response on a pin, 
the pin is considered BAD. 

• If ALL stimulus programs give GOOD responses on the 
pin, the pin is considered GOOD. 

• Otherwise, the pin is considered UNKNOWN. 



SUMMARY OF GFI COVERAGE 7.6. 

The 9 100 A provides a convenient means to check the 
completeness of the information you have entered into the GFI 
database for a particular UUT. When viewing the UUT 
directory display, you can press the SUMMARY softkey to 
request generation of a summary of GFI coverage for that 
particular UUT. The compiled database (GFIDATA or 
UFIDATA) will be examined and a summary will be generated, 
displayed on the monitor, and stored in a UUT text file that you 
specify. If you press the Shift key on the programmer's 
keyboard and the SUMMARY softkey, the summary will appear 
on the monitor without sending a copy to a text file. 



Creating a Summary of GFI Coverage 

The following procedure is used to generate a Summary of 
GFI Coverage for a UUT: 

1 . Press the EDIT key on the operator's keypad to enter 
the Editor (unless you are already in the Editor). 
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2. Use the EDIT key on the Programmer's Keyboard to 
enter the name of the UUT so that the UUT directory 
for this UUT is displayed on the monitor. The UUT 
directory you have selected must contain a compiled 
database (either GFIDATA or UFIDATA). 

3. Press the SUMMARY Softkey (F8) and the 9100A 
will issue the prompt shown below to ask for a text 
file name: 

Generate GFI Suinmary to TEXT file 



The Summary of GFI Coverage to be generated will 
be stored in this text file. 

4. Type in the text file name you wish and press the 
Return key. The 9 100 A will then begin generating 
the Summary of GFI Coverage for the UUT and will 
display the results on the monitor. 

When the generation is complete, the following message will 
appear on the monitor: 

Press Msgs key to continue 

When you press the Msgs key on the programmer's keyboard, 
the UUT directory display will reappear on the monitor. You 
can use the Edit key on the programmer's keyboard to access the 
text file you generated. 
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Statistical Summary 

The first part of the Summary of GFI Coverage is a statistical 
summary of the UUT, based on the GFI database you have 
provided. Figure 7-4 shows a typical example of such a 
summary. Each entry in the summary is described below: 

• Summary for /<disk drive>/<UUT>: In Figure 7- 
4, HDR is the disk drive and the UUT directory name is 
EXAMPLE. 

• Parts: The number of unique part types in the UUT, 
based on the reference designator list 

• Reference Designators: The number of reference 
designators in the UUT, based on the node list. 

• Connected Pins: The number of UUT pins that are 
connected to other pins on the UUT, based on the node 
list. 

• Unconnected Pins: The number of UUT pins that are 
not connected to any other UUT pins, based on the node 
list. 

• Total Pins: The total number of pins on the UUT. 

• Programs: The number of TL/1 programs that can be 
used by GFI as stimulus programs. This number is equal 
to the number of response files. 

• Testable Connected Pins: The number of connected 
pins that can be tested by GFL Testable pins have either 
been characterized with LEARN, or are a member of a 
node that has been characterized with LEARN. 

• Testable Unconnected Pins: The number of 
unconnected pins that can be tested by GFL Testable 
unconnected pins have been characterized by LEARN and 
appear in a response file. 

• Total Testable Pins: The total number of UUT pins 
that can be tested with GFI, given the database you have 
entered. 



7-19 



Summary for /HDR/EXAMPLE : 

53 Parts 

167 Reference Designators 

1694 Connected Pins 

225 Unconnected Pins 

1919 Total Pins 

42 Programs 

1688 Testable Connected Pins 

16 Testable Unconnected Pins 
1704 Total Testable Pins 

6 Untestable Connected Pins 
209 Untestable Unconnected Pins 
215 Total Untestable Pins 

99% Test Coverage of Connected Pins 
88% Test Coverage of Total Pins 



Figure 7-4: Statistical Summary Display for a UUT 
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Untestable Connected Pins: The number of 
connected pins that cannot be tested with GFI, due to an 
incomplete database. 

Untestable Unconnected Pins: The number of 
unconnected pins that cannot be tested with GFI, due to an 
incomplete database. 

Total Untestable Pins: The total number of UUT pins 
that cannot be tested with GFI, given the database you 
have entered. 

Test Coverage of Connected Pins: The percentage 
of connected pins on the UUT that can be tested with GFI, 
given the database you have entered. A figure of less than 
100% indicates an incomplete database. 

Test Coverage of Total Pins: The percentage of 
UUT pins that can be tested with GFI, given the database 
you have entered. This figure is typically less than 100% 
because a UUT often has unused pins. 



Pin Coverage 



The second part of the GFI Summary of Coverage display is a 
matrix showing how component pins are tested with the 
database you have provided. Figure 7-5 shows a partial 
example of a pin coverage matrix. The matrix is organized with 
the reference designators listed vertically (in the left-most 
column) and with component pin numbers listed horizontally. 
The number of pins per line will be the number required by the 
largest component in the list. If more than 35 pins are required, 
the display will produce a second list of reference designators 
following the first list and this second set will have pin numbers 
starting with 36 and continuing up from there. 

Each component pin has a one-character symbol that shows how 
GFI looks at the pin given the database you have provided. The 
table at the bottom of Figure 7-5 shows the meaning of each 
symbol that is possible: 



%& 
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Pin Coverage: 



12 3 4 5 6 7 



11111111112222222222333333 
901234567890123456789012345 



C15 10 

C16 I I 

C17 10 

J5 I**II***I**IIIIIIIIIIIIIIIIIIIIIIII 

J6IIIII 

Ql Oil 

02 on 

RIO O I 

Rll 10 

R12 10 

51 II 

52 I I 

U10 IIIIIBIIBIIBIIBBIIBI 

Ull *I*IIII*III*000*OBBBBI*OBBBB****0*I 

U12 OOIOIOOIOIIOIOII 

U13 IOIOIOGOIOIOIP ... 

U14 0**00***1**000000000000000001110001 



Symbol 

I 
o 

B 

p 

G 

* 



Meaning 

The pin is testable as an input only. 

The pin is testable as an output only. 

The pin is testable as both an input and an output. 

The pin is testable as a power pin. 

The pin is testable as a ground pin. 

The pin is not testable (because it has no associated 

stimulus program or no known-good 

response stored for this pin). 
There is no such pin in the database. 



Figure 7-5: Pin Coverage Display for a UUT 
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FAULT CONDITION EXERCISERS 7.7. 

When the 9100A/9105A detects a fault, and a fault condition 
handler is not defined for the fault condition raised, a fault 
message will appear on the operator's display. At this point, the 
operator can press the LOOP key on the operators keypad to 
repeatedly reproduce the fault so that it can be isolated manually. 
To do so requires that a fault condition exerciser exist for the 
fault condition that was raised. If the exerciser exists, it is 
invoked continually until the operator presses the STOP key on 
the operator's keypad. 

A fault condition exerciser is a software block designed 
specifically to reproduce a fault condition in a UUT. Two types 
of exercisers are available: built-in exercisers and user-defined 
exercisers. 

When a fault condition is raised by a built-in stimulus function 
(such as read, write, ramp, toggle, or rotate) or a built-in test 
function (such as testbus, testramfast, testramfull, or 
testromfull), the 9100A/9105A has a pre-defined sequence of 
commands that exercise the fault when the LOOP key is pressed. 
These are called built-in fault condition exercisers. In addition, 
you as a programmer can write your own fault condition 
exercisers for fault conditions that you define or to replace the 
built-in fault condition exercisers. When one of these fault 
conditions is encountered and the LOOP key is pressed, the fault 
condition exerciser with the matching name is invoked. 

If a fault condition exerciser for the displayed fault condition is 
found when the LOOP key is pressed, the fault condition 
exerciser is invoked repeatedly to stimulate the UUT. This 
allows the probe to be used to examine node responses in the 
circuit and to trace faulty circuit operation to its cause. 



o 
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REPAIR AFTER TROUBLESHOOTING 7,8. 

When GFI terminates, it will often display one of the following 

messages: 

• Open circuit 

• Bad IC or output loaded. 

When GFI reports an open circuit, it has found an input which is 
bad even though the signal source on that node is good. To 
repair the node: 

1 . Retest both ends of the node to make sure the output 
was properly probed. 

2. Confirm the open circuit with an ohmmeter. 

3. Trace along the node with the ohmmeter until the 
open point is found. 

4. If the node is connected properly, check for: 

- An error in the node list entry for the failed node. 

- Marginal measurements due to the frequency or 
timing of signals on the node. Ringing may be 
occurring on the node, or the time between the 
sync and the signal transitions may be marginal. 
Change the stimulus setup or the sync timing to 
correct the problem (see Section 8.5 on adjusting 
sync timing). 

When GFI reports a bad IC or output loaded, it has found all 
good inputs and one or more bad outputs. In this case, 
determine whether the part is bad or the output is loaded. To do 
this, test the component by overdriving its inputs with the I/O 
module while measuring level history or CRC signatures. 
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In doing so, determine whether: 

• The level history showed that the line went to a high and 
low state. If so, the node is only loaded part of the time, 
or the component is bad. 

• The node is loaded. If the component is good but the node 
is bad, the node must be loaded. The cause of a loaded 
node can be: 

- A short to another node, the power supply, or 
ground. 

- A damaged IC loading the node. Example 1 in 
Figure 7-6 shows a bad input at U6 causing node 
A to be loaded. 

- Another output source is also driving that node. 
Check the enable and control lines of any other 
devices that can drive the node. Example 2 in 
Figure 7-6 shows node A to be loaded because 
both Ul and U5 are attempting to drive the node 
at the same time. Ul is operating as it should but 
the U5 enable-line state is incorrect and U5 is 
also driving the same node. 

Operators should be provided with a procedure for tracing short 
circuits. For example, a milliohmmeter can be used to determine 
the point at which a node is shorted. To do this, attach one lead 
of the milliohmmeter to the faulty node. With the other lead, 
look for low resistance paths. 
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Figure 7-6: Node Loading 
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Section 8 

Glossary 



If you cannot find a term in the glossary, search the index for a 
reference to that term. 



Active Edge 

A signal transition used to initiate action. 

Address Space 

A section of memory reserved for a particular use, such as the 
stack. The term "decoded address space" implies memory 
residing in physically separate chips (selectively enabled by a 
"decoder"), such as a frame buffer, character generator, or the 
control registers inside a peripheral chip. 

Aliasing 

A condition where a component address responds to more than 

one combination of address bus bits. 

Assert 

To cause a signal to change to its logical "true" state. 

Asynchronous 

Not synchronized to the microprocessor or not synchronous to 

any clock signal 
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Automated Test 

An automated activity that verifies the correct operation of a 
circuit by comparing its output to the expected output. 

Automated Troubleshooting 

An automated process of locating a fault on a UUT. 

Backtracing 

A procedure for locating the source of a fault on a UUT by 
checking logic along a logical path from bad outputs to bad 
inputs until the point where no bad inputs are found. 

Bus 

A group of functionally similar signals. 

Bus Contention 

A situation where two or more bus devices are trying to put 
different data onto the same bus. 

CAD 

An acronym for Computer- Aided Design. CAD systems let the 
user create, manipulate, and store designs on a computer. 

Comment 

Text in a program that is not executed. A comment in a TL/1 
program or a node list must begin with an exclamation point (!). 

Component 

A passive or active part on a UUT. 

Control Line 

A signal that comes out of a microprocessor and is used to 
control the UUT. 

CRC Signature 

CRC is an acronym for Cyclic Redundancy Check. A CRC 
signature is a compression of a long data stream into a 16-bit 
number. 

Cursor 

A symbol on a display (usually a box or an underscore) that 
indicates where a typed character will appear. 
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Data Bus 

A set of signal paths on which parallel data is transferred 
between two or more devices. 

Device 

L Refers to the probe, an I/O module, a reference designator, 
or the pod. 2. Also used with I/O operations to specify a port 
or a disk drive. 

DIP 

An acronym for Dual In-line Package. A DIP has an equal 
number of pins on each of its long sides. See also SIP. 

Directory 

A collection of related sets of data (files, for example) on a disk. 

Drivability 

Testing whether lines can be driven to the appropriate active high 
or active low level. 

Dynamic Coupling 

Data in one memory location is affected by combinations of data 
in other memory locations. 

Edge 

The transition from one voltage level to a different voltage level. 

Exerciser 

See Fault Condition Exerciser. 

External Synchronization 

Synchronizing a node response measurement using signals 
external to the pod. 

Fault 

A defect in a UUT that causes circuitry to operate in a manner 
that is inconsistent with its design. 

Fault Condition 

A recognition by the 9100A/9105A that a fault exists on the 
UUT. 
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Fault Condition Exerciser 

A group of statements that attempts to repetitively reproduce the 
conditions that generate a fault condition. (Sometimes called just 
an "exerciser.") 

Fault Condition Handler 

A group of statements that is executed when a particular fault 
condition occurs. (Sometimes called just a "handler.") 

Fault Condition Raising 

The generation of a fault condition either from detecting a fault 
on a UUT or from using a TL/1 fault statement 

Feedback Loop 

A circuit in which one or more outputs is routed to the circuit's 
input. 

Forcing Line 

Input to the microprocessor that forces it to a particular known 
state. 

Functional Test 

An activity that verifies the correct operation of a circuit by 
comparing its output to the expected output. 

GFI 

See Guided Fault Isolation. 

GFI Summary 

A record of the components that have been tested by GFI. 

Go/No-Go Test 

A pass/fail test; either a unit passes or it doesn't. 

Guided Fault Isolation 

An algorithm that uses backtracing to troubleshoot a UUT. 

Handler 

See Fault Condition Handler. 
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Hexadecimal 

Pertaining to the base 16 numbering system. (Often abbreviated 
as "hex.") 

I/O 

An abbreviation for Input/Output. The transfer of data to and 
from devices other than the local memory of the microprocessor 
system. 

I/O Module 

An option for the 9100A/9105A that allows simultaneous 
stimulus or response for multiple points on a UUT. 

Level History 

A character string that represents a record of the logic levels 
measured at a point over a period of time. "1", "X", and "0" 
represent high, invalid, and low states, respectively. 

Library 

A directory that contains a collection of only a particular type of 
file. The 9100A/9105A uses four libraries: a part library, a 
program library, a pod library, and a help library. 

Mask 

A value where each logic "1" represents a bit that is to be acted 
on. 

Monitor 

A 24-line, 80-column video display that connects to the rear 
panel of the 9100A/9105A. 

Node 

A set of points that are all electrically interconnected. 

Node List 

A file containing a description of the interconnection of all pins 
on a UUT. 

Operator 

1. A symbol that acts on one or more values or expressions to 
produce another value. 2. A person who uses the 9 100 A/ 
9 105 A for testing or troubleshooting. 



8-5 



Operator's Display 

Three-line display on the mainframe of the 91Q0A/9105A. 

Operator's Interface 

The operator's display and the operator's keypad. 

Operator's Keypad 

The set of keys on the front panel of the base unit of the 
9100A/9105A. 

Overdrive 

To put a logic state on a signal line by applying more power than 
the normal driver for that node. This is how the 9 100 A/9 105 A 
injects signals into the UUT. 

Part Description 

A file that describes a component on a UUT. 

Part Library 

A library of part descriptions. 

Pod Library 

A library of pod descriptions, each of which contains a pod 
database and pod-related TL/1 programs. 

Pod Synchronization 

Synchronizing a node response measurement using signals 
generated by the pod to indicate the sampling time. 

Priority Pin 

A pin that the GFI program will test first if a particular node is 
bad. 

Probe 

A hand-held device that can stimulate and measure any single 
point on the UUT. 

Program Library 

A library of programs that can be called by any program in the 
userdisk. 
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Programmer's Interface 

The monitor and the programmer's keyboard. 

Programmer's Keyboard 

The keyboard that connects to the side panel of the 9 100 A. 

Raise 

See Fault Condition Raising. 

Reference Designator 

A one to ten character string naming a component on the UUT. 

Related Input Pin 

An input pin on a component that affects an output pin on that 
same component. 

Response File 

A file containing data generated by executing a specific stimulus 
program to a UUT and recording the responses from its 
execution. 

RUN UUT Test 

A feature that allows the normal operation of a UUT using its 
own program. 

Signature 

See CRC Signature. 

SIP 

An acronym for Single In-line Package. See also DIP. 

Softkey 

A key that has its function determined by software. 

State Machine 

A circuit which produces output signals in response to input 
signals and its own internal state. Typically used to generate a 
sequence of control signals, as in a bus interface. 
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Stimulus Program 

A program that exercises a circuit while the activity on circuit 
nodes are recorded to see if the circuit produces the same 
response as a known-good circuit. 

String 

A group of characters enclosed in double-quote characters (") 
and manipulated as a single entity. 

Synchronous 

Coordinated to the transitions of a clock signal. 

Termination Status 

An indication of whether a UUT passed a test. 

Timeout 

A condition in which an expected event has not occurred within 
the expected time period. 

Toggle 

Change to the complementary logic state. 

Transition Count 

A record of the number of times the logic level at a node changes 
from low to high within a period of time. 

Troubleshooting 

A process of locating the area of a UUT that is causing a fault. 

Userdisk 

1. A diskette containing test programs and information about a 
particular UUT. 2. The current disk drive that is used as a 
source for UUT programs and data. 

UUT 

Unit Under Test. A physical item, i.e., a board or a system to 
be tested. 

UUT Directory 

A set of files that contain information about a particular UUT. 
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Wait State 

A bus cycle which is too short for a slow chip is lengthened by 
the insertion of one or more clock cycles, called wait states. 

Watchdog Timer 

A circuit which produces a signal, typically a reset or high- 
priority interrupt, if a timeout condition is met. For example, an 
excessive number of wait states may trigger a watchdog timer 

Wildcard 

A symbol that represents any sequence of characters. The 
9100A/9105A uses the asterisk character (*) for this purpose. 

Window 

An area of the monitor reserved for certain information to be 
displayed. 
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Appendix A 

Demo/Trainer UUT 

Reflist 



NAME: REFLIST 
DESCRIPTION: 



SIZE: 3,555 BYTES 







TESTING 


REF 


PART 


DEVICE 


R72 


RESISTOR 


PROBE 


R73 


RESISTOR 


PROBE 


R4 


RESISTOR 


PROBE 


R7 9 


RESISTOR 


PROBE 


R78 


RESISTOR 


PROBE 


R61 


RESISTOR 


PROBE 


R62 


RESISTOR 


PROBE 


R63 


RESISTOR 


PROBE 


R64 


RESISTOR 


PROBE 


R65 


RESISTOR 


PROBE 


R70 


RESISTOR 


PROBE 


C4 


CAPACITOR 


PROBE 


C5 


CAPACITOR 


PROBE 


C8 


CAPACITOR 


PROBE 


C9 


CAPACITOR 


PROBE 


C13 


CAPACITOR 


PROBE 


C15 


CAPACITOR 


PROBE 


C16 


CAPACITOR 


PROBE 


C17 


CAPACITOR 


PROBE 


U74 


2016 


I/O MODULE 


U85 


2016 


I/O MODULE 


U72 


2674 


I/O MODULE 


U78 


2675 


PROBE 


Ull 


2681 


PROBE 


U77 


27128 


I/O MODULE 


U30 


27256 


I/O MODULE 
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U2 9 

U28 

U2 7 

Ql 

Q2 

CI 

R35 

Rl 

R7 7 

R80 

R15 

R14 

R16 

R13 

R17 

R12 

R18 

Rll 

R2 7 

R25 

R2 4 

R2 8 

R2 9 

R23 

R30 

R19 

R68 

R69 

R2 

R21 

R22 

R34 

R33 

R3 

R5 

R6 

R7 

R8 

R32 

R31 

R2 6 

R9 

R2 

U34 

U35 

U3 6 

U37 

U38 

U3 9 

U40 



27256 
27256 
27256 

TRANSISTOR 

TRANSISTOR 

CAPACITOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

RESISTOR 

4164 

4164 

4164 

4164 

4164 

4164 

4164 



I/O MODULE 

I/O MODULE 

I/O MODULE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

PROBE 

I/O MODULE 

I/O MODULE 

I/O MODULE 

I/O MODULE 

I/O MODULE 

I/O MODULE 

I/O MODULE 
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U41- 

U48 

U49 

U50 

U51 

U52 

U53 

U54 

U55 

R67 

C6 

C7 

R71 

RIO 

R66 

U14 

J5 

Ul 

U15 

U31 

U58 

U2 4 

U5 

U64 

U57 

U19 

U4 

U63 

U5 6 

U21 

U8 

U9 

U3 

U23 

U44 

CR1 

J2 

J3 

J6 

U73 

U83 

U84 

U65 

U66 

U33 

U47 

U61 

U70 

U71 

U62 



4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


4164 


I/O 


MODULE 


RESISTOR 


PROBE 


CAPACITOR 


PROBE 


CAPACITOR 


PROBE 


RESISTOR 


PROBE 


RESISTOR 


PROBE 


RESISTOR 


PROBE 


80286 


PROBE 


CONN 6 8 


PROBE 


82284 


I/O 


MODULE 


82288 


I/O 


MODULE 


8255 


I/O 


MODULE 


7400 


I/O 


MODULE 


7400 


I/O 


MODULE 


7400 


I/O 


MODULE 


7402 


I/O 


MODULE 


7404 


I/O 


MODULE 


7404 


I/O 


MODULE 


7408 


I/O 


MODULE 


7408 


I/O 


MODULE 


7410 


I/O 


MODULE 


74138 


I/O 


MODULE 


74138 


I/O 


MODULE 


74138 


I/O 


MODULE 


74245 


I/O 


MODULE 


74245 


I/O 


MODULE 


7474 


I/O 


MODULE 


DIODE 


PROBE 


CONN__RS232 


PROBE 


CONN_VIDEO 


PROBE 


CONNJKEYBD 


PROBE 


74157 


I/O 


MODULE 


74157 


I/O 


MODULE 


74157 


I/O 


MODULE 


74257 


I/O 


MODULE 


74257 


I/O 


MODULE 


7SEGLED 


PROBE 


7SEGLED 


PROBE 


7400 


I/O 


MODULE 


7400 


I/O 


MODULE 


7400 


I/O 


MODULE 


7404 


I/O 


MODULE 
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U5 9 

U80 

U81 

U7 

U25 

02 6 

U2 

U13 

U43 

017 

075 

068 

069 

032 

046 

06 

079 

060 

045 

086 

087 

010 

02 

U16 

U22 

076 

042 

067 

012 

J4 

018 

082 

088 

Yl 

S4 

S3 

S2 

SI 

S6 

DS1 

Zl 



74109 


I/O 


MODOLE 


7410 


PROBE 


7410 


PROBE 


74112 


I/O 


MODOLE 


74112 


PROBE 


74125 


I/O 


MODOLE 


74148 


I/O 


MODULE 


7414 


I/O 


MODULE 


74164 


I/O 


MODULE 


74164 


I/O 


MODULE 


74175 


I/O 


MODULE 


74244 


I/O 


MODOLE 


74244 


I/O 


MODOLE 


74244 


I/O 


MODOLE 


74244 


I/O 


MODOLE 


7430 


I/O 


MODOLE 


7430 


I/O 


MODOLE 


7431 


I/O 


MODOLE 


7432 


I/O 


MODOLE 


74373 


I/O 


MODOLE 


74373 


I/O 


MODOLE 


74373 


I/O 


MODOLE 


74374 


I/O 


MODULE 


74374 


I/O 


MODULE 


74374 


I/O 


MODULE 


74374 


I/O 


MODULE 


74390 


I/O 


MODULE 


74590 


I/O 


MODULE 


MAX232 


PROBE 


PWRCONN 


PROBE 


OSCILLATOR 


PROBE 


74175 


PROBE 


7486 


PROBE 


XTAL 


PROBE 


KEYSWITCH 


PROBE 


KEYSWITCH 


PROBE 


KEYSWITCH 


PROBE 


KEYSWITCH 


PROBE 


KEYSWITCH 


PROBE 


LED 


PROBE 


NETWORK10 


I/O 


MODULE 



HUHS 
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Appendix B 

Demo/Trainer UUT 
Node List 



NAME : 


NODELISI 














DESCRIPTION: 










SIZE 


: 16,4 92 BYTES 


U23-11 


U41-2 


U69-17 


U30-11 


U28-11 


U41-14 


Zl-10 




U23-12 


U40-2 


U40-14 


U69-15 


U30-12 


U28-12 


Zl-9 




U23-13 


U39-2 


U39-14 


U69-13 


U30-13 


U28-13 


Zl-8 




U23-14 


U38-2 


U38-14 


U69-11 


U30-15 


U28-15 


Zl-7 




U23-15 


U37-2 


U37-14 


U69-8 


U30-16 


U28-16 


Zl-6 




U23-16 


U36-2 


U36-14 


U69-6 


U30-17 


U28-17 


Zl-5 




U23-17 


U35-2 


U35-14 


U69-4 


U30-18 


U28-18 


Zl-4 




U23-18 


U34-2 


U34-14 


U69-2 


U30-19 


U28-19 


Zl-3 




U58-8 


U34-15 


U35-15 


U36-15 


U37-15 


U38-15 


U39-15 


U40-15 U41-15 


R69-1 


R72-1 


U88-8 












U84-6 


U72-32 














R14-1 


U46-12 














R13-1 


U4 6-14 














R12-1 


U46-16 














Rll-1 


U46-18 














R18-1 


U46-3 














R17-1 


U46-5 














R16-1 


U4 6-7 














R15-1 


U46-9 














U32-11 


U31-40 














R27-1 


U32-9 














R25-1 


U32-12 














R24-1 


U32-14 














R23-1 


U32-16 














R19-1 


U32-18 














R30-1 


U32-3 














U32-13 


U31-39 














R28-1 


U32-7 














U32-15 


U31-38 















B-1 



R29-1 


032-5 


032-8 


031-1 


R27-2 


033-7 


R19-2 


033-1 


U2-5 1 


J66-6 021-2 U30-2 6 U2 9-2 6 02 8-26 U27-2 6 


U84-3 


072-31 


084-10 


072-33 


U16-15 


065-5 084-11 011-4 072-38 031-8 O30-9 


02 8- 


9 U27-9 


011-36 


Yl-1 C8-1 


011-37 


Yl-2 C9-1 


016-19 


061-9 021-4 062-9 062-11 


070-11 


081-5 


022-9 


061-10 057-13 062-13 


065-1 


066-1 O60-7 


03-18 


048-2 048-14 068-2 010-19 011-21 072-1 


02 9- 


19 027-19 


02-6 


J66-3 021-1 O30-2 029-2 028-2 027-2 


R25-2 


033-8 


R24-2 


033-10 


R23-2 


033-13 


R29-2 


033-11 


032-6 


031-2 


032-2 


031-4 


032-4 


031-3 


046-11 


031-22 


R12-2 


047-13 


R17-2 


047-11 


R13-2 


047-10 


R14-2 


047-8 


R15-2 


047-7 


Rll-2 


047-1 


058-2 


08-14 


061-1 


062-12 


061-4 


062-10 


043-11 


061-12 067-11 067-13 044-1 044-13 059 


061-6 


068-1 068-19 074-21 


061-3 


069-1 069-19 085-21 


O70-3 


071-2 


O70-6 


071-4 


O70-8 


071-5 


056-10 


021-15 072-2 


075-5 


083-10 072-29 


U68-3 


074-9 077-6 


068-5 


074-10 077-5 


U68-14 


074-15 077-24 


076-6 


078-4 


076-5 


078-36 


088-9 


078-29 


087-13 


077-16 



029-9 \ 



031-27 \ 



-13 



B-2 



U87-8 


U77-15 




U87-17 


U77-18 




087-7 


U77-13 




087-18 


U77-19 




075-2 


U77-10 




U75-7 


U77-9 




U75-10 


U77-8 




U86-19 


U78-19 




U87-14 


U77-17 




087-3 


U77-11 




U87-4 


U77-12 




U86-15 


U78-17 




U86-16 


U78-16 




U86-12 


U78-25 




U86-6 


U78-18 




U69-9 


U86-13 


085-13 


069-18 


085-17 


U77-26 


U72-23 


078-11 




069-12 


U86-8 


085-14 


U80-8 


U81-13 




080-10 


U81-10 


082-6 


U80-12 


081-1 




O80-2 


070-5 071-12 


U80-4 


O70-9 081-11 


080-6 


081-2 




U80-11 


079-11 


082-14 


O80-5 


079-4 U62-2 


U80-3 


070-13 


079-5 


U70-12 


076-11 


07 9-3 


U71-13 


079-6 


081-3 


022-5 


021-6 




U83-9 


074-3 U85-3 


U3-11 


055-2 U55-14 



081-4 082-15 
082-10 



081-9 082-3 073-1 083-1 084-1 
08 6-11 087-11 072-16 07 8-33 



062-5 



082-11 



068-17 010-2 011-28 072-8 031-34 \ 



028-24 027-24 
028-5 027-5 



028-23 U27-23 



029-11 027-11 
032-17 031-37 

02-15 065-6 073-11 030-24 029-24 
016-5 066-5 083-11 O30-5 U29-5 
046-13 031-23 
046-8 031-21 

02-9 065-13 030-23 029-23 
027-22 06-5 045-3 028-22 
034-4 035-4 03 6-4 037-4 038-4 039-4 04 0-4 041-4 04 8-4 

049-4 O50-4 051-4 052-4 053-4 054-4 055-4 064-8 063-8 
034-5 035-5 03 6-5 065-4 067-15 037-5 038-5 03 9-5 04 0-5 N 

041-5 U48-5 049-5 O50-5 051-5 052-5 053-5 054-5 055-5 
034-6 035-6 03 6-6 065-9 067-2 037-6 038-6 039-6 04 0-6 \ 

041-6 048-6 04 9-6 O50-6 051-6 052-6 053-6 054-6 055-6 
034-7 035-7 036-7 065-7 067-1 037-7 038-7 03 9-7 O40-7 \ 

041-7 048-7 049-7 O50-7 051-7 052-7 053-7 054-7 055-7 
034-3 035-3 036-3 037-3 038-3 039-3 040-3 041-3 048-3 \ 



\ 



B-3 



049-3 050-3 U51-3 U52-3 U53-3 U54-3 U26-8 U55-3 
034-12 035-12 U3 6-12 U65-12 U67-3 037-12 038-12 03 9-12 \ 
040-12 U41-12 U48-12 U49-12 U50-12 051-12 U52-12 053-12 \ 
054-12 U55-12 

U66-4 067-4 03.7-11 038-11 039-11 \ 
049-11 050-11 051-11 052-11 053-11 \ 



034-11 035-11 036-11 

040-11 041-11 048-11 

054-11 055-11 
034-10 U35-10 036-10 

040-10 041-10 048-10 

054-10 055-10 
034-13 035-13 036-13 066-9 067-6 \ 

037-13 038-13 03 9-13 04 0-13 041-13 

051-13 052-13 053-13 054-13 055-13 
058-11 048-15 049-15 050-15 051-15 

055-15 
06-2 08-11 
06-3 08-10 
05-10 011-9 



066-7 067-5 037-10 038-10 03 9-10 \ 
049-10 050-10 051-10 052-10 053-10 \ 



048-13 049-13 050-13 



052-15 053-15 054-15 



072-3 031-36 015-11 



057-2 
083-12 
06-11 
016-2 
043-9 
02-12 
056-1 
034-9 
041-9 



05-13 
074-4 

081-8 
066-11 
056-12 
065-10 
044-9 
U35-9 
048-< 



085-4 



083-5 O30-4 02 9-4 02 8-4 027-4 



030-21 029-21 028-21 027-21 



056-9 021-14 
046-15 031-24 
046-17 031-25 
076-15 078-38 
075-15 077-7 
069-14 086-7 
045-1 045-4 
045-5 09-9 
02-16 065-3 
02-19 066-14 
046-6 031-20 
046-4 031-19 
046-2 031-18 
016-6 066-2 083-14 
03-14 052-2 052-14 

029-15 027-15 
03-13 053-2 053-14 

029-13 027-13 
088-4 078-28 
082-1 013-10 
03-15 051-2 051-14 

029-16 U27-16 
022-4 J5-66 014-66 



073-5 
064-12 

036-9 066-12 
049-9 O50-9 

011-39 



067-7 
051-9 



037-9 038-9 039-9 
052-9 053-9 054-9 



O40-9 \ 
055-9 



085-15 
056-3 079-2 057-1 015-8 
030-20 029-20 

073-14 030-25 02 9-25 028-25 02 7-25 
083-2 O30-3 029-3 028-3 027-3 



O30-6 02 9-6 02 8-6 02 7-6 
068-11 010-9 011-19 072-11 031-31 



068-13 010-6 011-27 072-10 031-32 



U68-8 010-12 011-2 6 072-12 031-30 



B-4 



U22-14 J5-13 U14-13 
U22-18 J5-15 U14-15 
U2-4 J5-17 U14-17 



J5-12 
J5-14 
C4-1 
C13-1 
J5-27 
J5-2 6 
J5-28 
U17-8 
U13-1 
J5-32 
J5-34 



Ul-4 U19-1 J5 
J5-51 U14-51 
U14-49 
U14-50 
U14-42 
U14-47 



U22-13 

U22-17 

U14-52 

J5-52 

U16-8 

U16-7 

U16-13 

Ul-10 

U7-1 
U16-14 
U16-18 
Rl-2 
U23-2 
U23-3 
U3-2 
U3-6 
U23-4 
U23-5 
U23-6 
U23-8 
U2-11 
U56-5 
U16-16 

U28 
U23-9 
U26-1 
U3-5 
U22-8 
U23-7 
U3-9 
J5-64 
U3-8 
U3-7 
U2-8 
U2-2 
U3-3 
U2-18 
U3-4 
U84-12 
U84-9 
Ul-16 
R2 6-1 
U16-12 

U27-8 
U6-4 U45-6 U30-22 
U21-13 U4-10 U31-6 
U3-12 U54-2 U54-14 



U14-12 
U14-14 



U14-27 
U14-26 
U14-28 
U44-3 U44-11 U59-4 J5-31 
U14-31 U15-2 
U14-32 
U14-34 

-63 



U4-12 U14-63 U15-1 



J5-49 
J5-50 
J5-42 
J5-47 
J5-45 
J5-43 
J5-39 
U16-11 
Ull-10 
U65-2 
-10 U27 
J5-37 
U13-4 
J5-44 
J5-1 
J5-41 
J5-36 
U13-12 



U14-45 

U14-43 
U14-39 
U22-11 
U72-1 
U84-14 
10 

U14-37 
U13-13 
U14-44 
U14-1 

U14-41 
U14-36 



U7-2 
U31-5 
Ull-2 



U15-S 
U15-12 
U72-37 



U31-9 U30-10 U29-10 



U14-64 



U30-27 U29-27 U28-27 U27-27 



J5-38 

J5-40 

J5-19 

U66-10 

J5-48 

J5-23 

J5-46 
U74-S 

U74-7 

J5-4 U14-4 U15-3 

U13-3 
U65-11 U84-5 Ull-6 U72-39 U30-8 U29-8 U28-8 



U29-22 



U14-38 
U14-40 
U14-19 

U21-3 
U14-48 

U14-23 

U14-46 
U85-8 

U85-7 
U14-4 



U68-15 U10-5 Ull-18 U72-9 U31-33 



B-5 



U29-12 U27-12 



R5-1 


31-1 U31-14 


R6-1 


32-1 U31-15 


R7-1 


33-1 U31-16 


R8-1 


34-1 U31-17 


U56-8 


U5-5 




U68-7 


U74-11 


U77-4 


U71-3 


J82-4 




U16-9 


U65-14 


U84-2 Ull-7 U30-7 U2 9-7 


U61-13 


U58-6 


U59-2 U59-3 U60-1 U63-9 


U58-12 


U62-8 




U56-13 


U59-12 


U13-2 


U65-15 


U66-15 


U44-5 U44-12 


U2-7 


J5-18 U14-18 


Ul-12 


U19-3 


J5-2 9 Ull-38 U13-11 U31- 


Ul-15 


J5-5 U14-5 U15-19 


U84-4 


U74-5 


U85-5 


U84-13 


U72-34 




U88-13 


U72-18 




U88-1 


U72-19 




U73-13 


U72-26 




U73-10 


U72-25 




U72-7 


U78-8 




U83-7 


U74-2 


U85-2 


U83-4 


074-1 


U85-1 


U6-8 


05-1 




U13-5 


U13-8 




R33-1 


U20-4 




U76-9 


U78-37 




R20-1 


R21-1 


R22-1 U12-2 


U19-2 


U7-3 




U43-8 


U42-3 




U86-9 


U78-14 




U17-9 


U4-11 


U5-2 


U7-5 


U8-4 




U19-4 


U7-15 




U45-9 


U56-6 




U84-7 


U74-6 


U85-6 


U20-6 


U10-7 




U76-19 


U63-4 


U63-13 


U20-2 


Ull-24 


R3-1 


U76-16 


U63-5 


U78-2 


U69-7 


U86-14 


U85-11 


U8-13 


U62-1 




U45-10 


U5-8 




U75-9 


U62-4 




U63-6 


U78-39 




U76-2 


U63-12 


U78-5 


U80-9 


U80-13 


U70-1 U70-4 U70-10 U82- 


U81-12 


U82-12 





U28-7 U27-7 



U14-29 
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U68-16 


U74-16 U77-21 


U75-13 


U83-3 


U72-27 


U68-12 


U74-1' 


t U77-25 


U57-6 


U5-12 




U69-5 


U86-17 


U85-10 


U69-16 


U85-16 U77-2 


J2-2 


U12-7 




J2-3 


U12-13 


R21-2 


Ul-13 


U42-4 




U25-1 


U25-9 


U78-32 


U80-1 


U61-2 


U61-5 U 


U71-9 


U79-8 




U60-2 


U60-5 


U60-15 


U20-9 


U10-3 




U20-7 


U10-4 




Ull-13 


U12-1C 




R34-1 


U25-1S 




U63-11 


U78-6 




U76-12 


U78-3 




U68-18 


U74-17 


U77-23 


U69-3 


U86-18 


U85-9 


U75-4 


U83-13 


U72-30 


U75-12 


U83-6 


U72-28 


U73-6 


U72-24 


U78-13 


U4-5 


J5-6 




U4-1 


J5-11 




Ull-35 


U13-6 




Ull-5 


U12-9 




U60-14 


U19-5 




U44-2 


U64-13 




Ull-14 


U12-11 




U4-2 


J5-9 U15-13 


U57-4 


U9-5 




U57-9 


U15-16 




U22-12 


U57-3 


U8-5 


U20-12 


Ull-15 


R2-1 


U3-17 


U4 9-2 


U49-14 I 


U2 9- 


18 U27- 


18 


U68-9 


U74-13 


U77-3 


U62-3 


U72-17 


U78-12 


U22-6 


U21-5 


U8-6 U 


U12-1 ( 


:15-1 




J6-2 


Ull-33 


U13-9 I 


U16-3 


J5-24 


U14-24 


U16-17 


J5-33 


U14-33 


R80-1 


J5-61 


U14-61 


R77-1 


J5-59 


U14-59 


U20-15 


J5-57 


U14-57 


R78-2 


J5-54 


U14-54 


U16-4 


J5-25 


U14-25 



U82-7 



U68-4 U10-16 Ull-25 U72-14 U31-28 



R31-1 C7-1 
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Ul-5 


U25-5 


J5-16 


U14-16 U2-3 


U3-1 


U23-1 U15-17 


Ul-2 


U4-6 


U26-2 


U14-65 


U45-8 


U24-5 U4-13 


U24-4 


U19-6 


U26-9 


U56-4 U15-9 


Ul-11 


R10-2 R9-2 C5-1 CR1-2 


R22-2 


J2-20 


J2-5 


U12-8 R20-2 


J2-4 


U12-14 


Ull-17 


J6-3 


U73-7 


U74-19 U85-19 


U62-6 


U74-20 U85-20 


U73-12 


U74-23 U85-23 


U73-9 


U74-22 U85-22 


Ull-11 


U12-12 


U12-3 


C15-2 


U12-4 


C17-1 


U80-7 




R10-1 


S6-1 


U3-19 


U23-19 U57-8 


U22-16 


U8-2 U9-2 


U22-15 


U8-3 U9-3 


U17-11 


U5-4 


U4-3 


U4-9 U10-1 U10-11 


U3-16 


U50-2 U50-14 U68-6 U10-15 Ull-20 U72-13 



U31-29 U29-17 U27-17 
U64-9 U24-6 
U6-6 U59-6 
U56-11 U4~8 



U61-8 


U79-12 






U61-11 


U59-13 






U57-5 


U8-12 






U56-2 


U67-14 


U44-6 




U45-2 


U9-7 


U28-20 


U27-20 


U58-1 


U8-15 






U44-8 


U63-10 






U57-12 


U58-1C 






U58-5 


U59-9 


U64-11 




U58-9 


U58-13 


U64-10 




U22-19 


U66-13 


U8-1 


U9-1 


U22-7 


J5-67 


U14-67 


U15-18 


U2-13 


J5-20 


U14-20 




U2-14 


J5-21 


U14-21 




U2-17 


J5-22 


U14-22 




R79-2 


J5-53 


U14-53 




U42-1 


U42-7 






U76-17 


U87-16 
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U76- 

U76- 

U4-4 

U12- 

U59- 

U76 

U88 

U88 

R73 

U12- 

U18 

U71- 

U58' 

R32- 

U76- 

U7 6 

U71- 

U71- 

R67 

U76 

R68 

R2 8 

R30 

R16 

R18 

U71 

R7 

R71 

R61 

U76- 

J2-7 

R35- 



J3-7 



U25-13 



13 U87-12 
8 U87-9 

U5-3 
6 C16-2 
10 U59-14 

U87-5 
J3-9 

J3-8 

R71-2 

C17-2 

U82-9 
U71-11 

U58-4 

J6-1 C6-1 
U87-15 

U87-2 

U82-5 

U82-13 

Q2-1 Ql-2 

U87-6 

R70-1 

U33-2 

U33-6 

U47-2 

U47-6 

U81-6 

R72-2 

Ql-1 

R62-1 
U87-19 
R4-1 
1 DS1-2 



U88-6 



R66-2 Q2-2 



R63-1 R64-1 R65-1 



U78-1 



! GROUND NODES 



9 U2-1 U2-10 U3-10 U6-7 U16-1 \ 
U22-10 U23-10 U26-7 U26-10 U34-16 \ 
U36-16 U37-16 U38-16 U39-16 U4 0-16 U41-16 U43 
U48-16 U49-16 U50-16 U51-16 U52-16 U53-16 \ 
U55-16 U56-7 U61-7 U65-8 U66-8 U67-8 U67-12 
U69-10 U70-7 U71-7 U75-8 U76-1 
U81-7 U86-1 U86-3 U86-4 U86-10 
U17-7 \ 

U42-15 U57-7 U58-7 U44-7 \ 
U73-15 U83-8 
U20-5 U20-8 
7 \ 



R73-1 Ul-3 Ul 
U16-10 U22-1 
U35-16 
U45-7 
U54-16 
U68-10 
U79-7 

U88-2 U88-5 U88-7 U88-10 
U42-2 U42-8 U42-12 U42-14 
U5 9-8 U82-8 U60-8 U7 3-8 
U84-15 U64-7 U24-7 U19-7 
J5-9 J5-35 J5-60 U4-7 U5 



U67-8 U67 

U76-10 \ 

U87-1 U87-10 



U58-7 
U83-15 
U21-8 



U44- 
U84- 
\ 



R4-2 U7-8 U8-8 U9-4 
U10-10 U10-13 U10-17 
U12-15 C16-1 U13-7 J4- 



\ 



U9-8 U10-8 
U10-18 Ull-22 J3-1 J3-6 
■6 J4-7 J4-8 J4-9 S4-2 



S3 



\ 
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S2-2 Sl-2 S6-2 U25-8 C5-2 U32-1 032-10 U32-19 U4 6-1 \ 

046-10 U46-19 Q2-3 U62-7 063-7 U74-12 U74-18 J6-4 C4-2 C13-2 \ 

U72-2 U85-12 U85-18 U7 7-14 077-2 U77-22 U78-9 \ 

U7 8-10 078-15 U7 8-20 U7 8-21 U78-22 U7 8-23 U78-2 4 U78-31 

U31-7 U30-14 02 9-14 U2 8-14 U27-14 U14-9 U14-35 U14-60 \ 

U15-6 U15-7 U15-10 Cl-2 C6-2 C7-2 \ 

U18-7 R35-2 R77-2 R80-2 C8-2 C9-2 Zl-1 

! POWER NODES 



U18-1 
R7-2 
R61 
Ul-1 
U22 
U38 
U45 
053- 
067- 
U76 
U88 
R2 6 
058- 
05 9- 
024- 
020- 
U7-1 
013- 
025- 
U32 
J6-5 
078- 
02 9- 
U15- 



DS1-1 
R8-2 
R62 
U2-2 

U22 

039- 
U4 7 

U54 
U67 
U7 9 
U17 

R9-1 



Rl-1 R34-2 R33-2 R3-2 U33-3 033- 
U80-14 R32-2 R31-2 R68-2 R69-2 
R63-2 R64-2 R65-2 Ul-1 Ul-6 
U3-20 U6-1 U6-12 U6-14 016-20 



14 R5-2 R6-2 
R67-1 \ 

Ul-17 \ 
\ 



023-20 02 6-14 034-8 U35-8 U36-8 
04 0-8 041-8 043-1 043-2 043-14 
04 7-14 04 8-8 04 9-8 O50-8 051-8 



2 



20 

8 

3 
8 055-8 05 6-14 061-14 U65-16 066-16 
-16 068-20 069-2 07 0-14 071-14 075-1 
1 07 9-14 081-14 086-20 087-2 U88-12 
-1 017-2 017-14 R66-1 R79-1 R78-1 \ 
J5-62 014-62 042-16 057-14 \ 
14 04 4-4 04 4-10 04 4-14 U59-1 05 9-5 05 9-15 
16 082-16 O60-6 060-16 073-16 083-16 084-16 
14 019-14 O20-1 O20-3 020-10 020-11 020-13 
16 U21-16 J5-30 04-14 05-14 07-4 \ 
6 U8-16 09-16 010-14 010-20 011-4 4 R2-2 012 

14 J4-10 J4-11 Cl-1 J4-12 J4-13 025-2 \ 
3 U25-4 025-10 025-11 025-12 025-14 025-16 CR1-1 
20 U4 6-2 Ql-3 062-14 063-14 074-2 4 \ 

072-3 6 072-4 085-24 077-1 077-2 7 07 7-28 07 8-7 
30 078-34 U78-35 078-40 031-26 O30-1 030-28 \ 
1 029-28 U28-1 028-28 U27-1 027-28 014-30 015-14 

15 015-20 



037-8 
\ 

052-8 
\ 
075- 
\ 



\ 



\ 



16 



064-14 
\ 

-16 \ 



! ONOSED OOTPUTS 

026-3 

073-4 

075-3 

075-6 

U75-11 

075-14 

086-2 

086-5 

015-4 

059-7 

042-5 

042-6 

042-13 
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U42-11 

U42-10 

U42-9 

U43-3 

U43-4 

U43-5 

U43-6 

U43-10 

U43-12 

U43-13 

067-9 

U31-13 

U31-12 

U31-11 

U31-10 

Ull-8 

Ull-40 

Ull-3 

Ull-43 

Ull-42 

Ull-41 

Ull-32 

Ull-31 

Ull-30 

Ull-16 

Ull-29 

U8-9 

U8-7 

U9-15 

U9-14 

U9-13 

U9-12 

U9-11 

U9-10 

U21-12 

U21-11 

U21-10 

U21-9 

U21-7 

U25-7 

U25-6 

U20-14 

U17-3 

U17-4 

U17-5 

U17-6 

U17-10 

U17-12 

U17-13 
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^masters 

! PROCESSOR ADDRESS LINES 

U14-34 

U14-33 

014-32 

U14-28 

U14-27 

U14-26 

U14-25 

U14-24 

U14-23 
014-22 
U14-21 
014-20 
U14-19 
U14-18 
014-17 
014-16 

U14-15 
014-14 

014-13 
014-12 

! BUFFERED ADDRESS LINES 

016-19 

U16-16 

016-15 

016-12 

016-9 

016-6 

016-5 

016-2 

02-19 

02-16 

02-15 

02-12 

U2-9 

02-6 

02-5 

02-2 



022-19 
022-16 
022-15 
022-12 
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U22-9 

U22-6 
U22-5 

! PROCESSOR DATA LINES 

U14-51 
U14-49 
U14-47 
U14-45 
U14-43 
U14-41 
U14-39 
U14-37 

U14-50 
U14-48 
U14-46 
U14-44 
U14-42 
U14-40 
U14-38 
U14-36 

! BUFFERED DATA LINES 

U23-18 

U23-17 

U23-16 

U23-15 

U23-14 

U23-13 

U23-12 

U23-11 

U3-18 

U3-17 
U3-16 
U3-15 
U3-14 
U3-13 
U3-12 
U3-11 
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Appendix C 

Subprograms for 
Functional Test and Stimulus 

Programs 



The following programs are included in this appendix: 
abortjest 
checkjoop 
checkjneas 
recover 
tst conten 
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program abort_test (ref } 



j i \i 11 m t i i i i i i i 1 i i I i J i i t i i i i 1 1 I I i HI!!!! ! 
FUNCTIONAL TEST of the Microprocessor Bus. 



■ 1 1 t t i i 1 1 1 t t t t i i 1 1 1 1 i i i i i t i t 



This program is called by many of the test programs after the test 
program has found a failing circuit. This program highlights the part 
with the FAILED test attribute, changes all parts with a TESTING test 
atribute to UNTESTED, and then checks to see if gfi has enough test 
results to make an accusation. If an accusation exists then the 
accusation is displayed. Otherwise a gfi hint is generated for the 
part and the test programs are terminated so that GFI can begin 
troubleshooting. 

TEST PROGRAMS CALLED: 
none 



GRAPHICS PROGRAMS CALLED: 
fail (part_number) 



Highlight part to be failed 



M l ? ? t t i i i i t t t t t n l l i i t i i t t t i i t ? i i i i i i t t t t i I I I i i i i i j j I I 



!!!!!!!!! 



m m t i 1 1 j !!!!!!! ! 



!!! 



Main Declarations 
i i i t t t 1 1 1 1 1 1 t i i i i 



!!!!!! 
!!!!!! 



I I i t t t M 1 



!!!!!!!!! 



declare 

string ref 

global numeric t2o 

global string array [1:107] part 

global numeric array [1:107] partatrb 



! The ref-pin of the failed part 
! Buffered I/O on /term2. 
! Part shape and positions 
! Attribute number of part 



Next three items relate to Test window displayed by disply_pcb{). 



global string testwindl = "\lB[12;65f\lB[Qm\lB[lm" 
global string testwind2 = H \lB[13;65f\lB[0m\lB[lm" 
global string undrtest = "\1B[15; 66f\lB[0m" 
end declare 



Place text in line 2 
Place text in line 3 
Place text in line 5 
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! Highlight Failed Part. 

n = instr(ref, "-") 

if n = then n = len(ref) + 1 

ic_num = (val {mid(ref, 2, n-2),16)) 

! convert decimal ic_num to hex 

declOO = ic_num / $100 

declO = (icjium - declOO * $100) / $10 

decl = (ic_num - declOO * $100 - declO * $10) 

hex_ic_num = declOO * 100 + declO * 10 + decl 

fail (hex_ic_num) 

I Change all parts with a TESTING attribute to an UNTESTED attribute and 
! display GFI TROUBLESHOOTING in the test window, 

for i = 1 to 107 

if partatrb[i] = 2 then untested(i) 
next 

print on t2o ,testwindl, " GFI ",testwind2, "TROUBLESHOOTING" 
print on t2o ,undrtest," » 

! If GFI has an accusation then display the accusation otherwise generate 
! GFI Hints. 

accusation = gfi accuse 
if accusation = "" then 

gfi hint ref 

fault 'gfi hints generated' ' please run gfi' 
else 

fault ' ' ' ' accusation 
end if 

end program 
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program check_loop 



j t t t t t t t i i i i i i t i I t i i t t i i > n i i I I I i ! t t ! n ! I I !!!!!!!!!!!!! ! !! !!!!!!!!!!! ! ! 
This program checks the DEMO/TRAINER UUT Loopback switches. If the 
loopback switches are not closed then a prompt is generated to close 
the loopback switches. Otherwise no prompt is generated. 

I I ! ! i !!!!!!!!!!!!!!!!!!!!!!!!!!! I! ! ! I! !!!!!!!!!!!!! ! ! ! ! ! ! ! I !!!!!!!!!!! ! 

function pmpt_lpbk 
declare 

string q 
end declare 

print "Close SW4-4, SW4-5 and SW6-4 for loopback" 
print "Press \lB[7m ENTER \lB[0m key to continue " 
input q \ print 
end function 

execute rs232_init() 

write addr $2006, data $AA 

wait time $200 

if ((read addr $2002} and $F> <> $D then 

execute pmpt_lpbk{) 

return 
end if 

write addr $201E, data $FF 
write addr $2016, data $BB 
wait time $200 

if (read addr $2016) <> $BB then 

execute pmpt_lpbk() 

return 
end if 

write addr $201C, data $FF 

if ((read addr $201A) and 2) <> then 
execute pmpt_lpbk() 

return 
end if 

end program 
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program check_meas (dev, start, stop, clock, enable) 



I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
Check status of External START, STOP, CLOCK, ENABLE lines, 
Return 1 if measurement is complete, display prompt to fix 
the external lines, wait for ENTER key, and return if the 
measurement times out. 
! mi t i i t t t t i i i i i j j i i j i j t t i i t t i t t n i i i j i ; J t t i i I j j t n ii ! ! ! ! ! i I I I! 



ttiiiiiiiii 



m 



t i i i i i m 



Main Declarations 

! m 1 1 1 1 1 1 1 1 1 || i i j i i i i i j j 1 1 || i i i t 1 1 1 1 1 1 t i i 1 1 1 1 i i i 1 1 1 1 t i i i i i 1 1 1 1 t 



declare string dev 

declare string start 

declare string stop 

declare string clock 

declare string enable 

!!! !! !!!!!!!!!!!!!!!!! I! !!!!!!! I !!!!! M !!!!!!!!!!!!!! I !!!!!!!!!!!!!! !! ! I ! 
! Main part of program ! 

I t t t t t t t t 1 i j j j ? j i i i i i i i i t t t i i t t j j i i j j j t i I i i j t j I i i ; ! M ! ! ! ! !I I ! ! ! ! H I ! ! ! ! ! ! 

times = 

loop while checkstatus (dev) <> $F and times < 100 

times = times + 1 
end loop 



If START fails then STOP, ENABLE and CLOCK will also fail. 

If ENABLE fails then CLOCK will also fail. 

Diagnose cause of failure and only display START if START fails. 

Do not display CLOCK when ENABLE line fails. 



if times < 100 then 

return (1) 
else 

tl = open device "/terml", mode "unbuffered" 

! turn autolinefeed off and clear screen 

print "\1B[2J\1B[201" 

n = checkstatus (dev) \ str = "" \ line = "" 

if (n and 4) = then 

line = line + "START " 
str = str + " START to " + start + ", " 
else 

if (n and 8) = and stop <> "*" then 
line = line + "STOP, " 
str = str + " STOP to " + stop + "," 
end if 

if (n and 2) = and enable <> "*" then 
line = line + "ENABLE " 

str = str + " ENABLE to " + enable + "," 
else if (n and 1) = then 
line - line + "CLOCK " 
str = str + " CLOCK to " + clock + ", " 
end if 
end if 

print "\lB[l;lf", "External line(s) ", line, "failed." 
print "\lB[2;lf", "Connect", str, "\lB[3;lf" 
print "Press \lB[7mENTER \lB[0m to REPEAT, \lB[7mN0 \lB[0m to CONTINUE" 

! Wait for ENTER key to be pressed. 
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input on tl , str 
print "\lB[20h\lB[2J" 
close channel tl 
if str = "\7F" then 

return (1) 
else 

return (0) 
end if 
end if 
end program 
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§1 



program recover 



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
This program recovers sync between the 82288 Bus Controller and the 
80286 pod. 

Some of the stimulus programs disable ready before performing stimulus 
which can cause the 80286 bus controller to get out of sync with the 
pod. The recover () program is executed to resynchronize the bus 
controller and the pod. 

TEST PROGRAMS CALLED: 
(none) 

GRAPHICS PROGRAMS CALLED: 
{none) 

Global Variables Modified: 

recover_times Reset to Zero 

I I I I I I 1 1 M M 1 I t 1 f 1 t t t t I I I I I I t t t t I I I I I I t t t t I I I 



I 1 1 1 

Main 



i i i t i i i i i j t 

Declarations 
i i i i i i i i i i i 



M! 



t t t t t t t t i 



III!!!!!! 



!!!I 



declare global numeric recover_times ! Count of executing recover (). 

!!!!!!!!!!!!!!!!!!!!! I !!!!!!!!!!!!!!!!!!!!!!! I !!!!!!!!!!!!! I! !!!!!!!!!!! ! 
! Main part of STIMULUS PROGRAM ! 

t t t t i i t i i i t i i t i t t t t t t tt i t t it j i i t t t T i t t j i i i t t i i i t i t i j J i i i i i i i j j j t t i i t i i i i i 

recover_times = recover_times + 1 

if recover_times <~ 1 then 

podsetup 'enable -ready' "off" ! POD is out of sync with 
setspace (getspace ("memory", "word") ) ! the 82288 bus controller 
read addr ! Read in memory space then 

write addr 0, data ! Write in memory space to 

podsetup 'enable -ready' "on" ! synchronize 82288 and POD. 

else 

podsetup 'enable -ready* "off" 

print "Please press the \lB[7mUUT RESET KEY \lB[0m" 

loop until (readstatus {) and $10) <> ! wait for RESET active. 

end loop 

podsetup 'enable -ready' "on" 

loop until (readstatus () and $10) = ! wait for RESET inactive, 
end loop 
print "\1B[2J" 
end if 
end program 
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program tst_conten (addr, data_bits) 



i i i i t i t m t i t t t t t t t i J t i i M t t » t t t m ;t t r t i t t t t j t t t j i ; i J J t t i i t t t t jj t t i t i i t t 
TEST to isolate DATA BUS CONTENTION to the failing part. 

This program attempts to determine the cause of Data Bus contention by 
testing the enable lines of all the devices on the Data Bus. This 
program performs several steps. First each device on the data bus is 
accessed and determined to be accessible or inaccessible. The 
variable bad_dev is a mask that records which devices failed. 

Many times when Data Bus contention exists, the device that has the 
bad enable lines can be accessed and the rest of the devices cannot be 
accessed. This program checks the mask to see if all except one 
device is bad and then tests the enable lines on the device that 
appeared good. ! 

If all devices are bad or more than one device is good then this test 
checks the enable lines of all the devices on the Data Bus by brute 
force . 



TEST PROGRAMS CALLED: 
abort_test (ref-pin) 



FUNCTIONS CALLED: 

testic {refname, pinl, pin2) 



MM 

Main 
i t i t 



I i i i i i i i 1 1 1 1 1 1 I i 

I I I I I I I I 1 1 1 1 1 I 1 1 

Declarations 
t 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 



If gfi has an accusation 
display the accusation else 
create a gfi hint for the 
ref-pin and terminate the test 
program (GFI begins trouble- 
shooting) . 



This function performs a gfi 
test on refname. Then the pins 
pinl and pin2 (which are the 
enable lines) are checked to 
see if they are bad. If so 
abort__test is called and GFI is 
started on the failing enable 
line. Otherwise all test info 
about the part is discarded 
using the gfi clear command. 
1 t r 



declare 

numeric addr 

numeric data_bits 

numeric bad_dev = 

numeric array [0:$15] ram_ic 

global string contention__checked 
end declare 



! Address where failure occured. 
! Mask of failing data bits. 
! Mask to record failing devices 
! Convert RAM bit to part number 
! Record that this test ran. 



i i J J J J J i J J J J J J t t t t it t i i i i J J J J j J i J J J J J J I t j I! m m ! ! t ! m ! M m M I I I I! ! J ! mm t 

! Functions ! 

I j j j j j j j j j ; j j ; ; j ij i j j j j j j j ; j 1 1 1 j j j j j j 1 1 1 j j j j j j i it i j j j j it i j j i j j j 1 1 1 1 j j j j j i 

function testic (ref, pin_a, pin__b) 
declare numeric ref 
declare numeric pin_a 
declare numeric pin_b 
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! convert decimal ref to hex 



declOO = ref / 100 
declO = (ref - declOO 
decl = (ref - declOO * 
href = declOO * $100 + 



r 100) / 10 
100 - declO * 10) 
declO * $10 + decl 



ref_a = "U" + str(href,16) + 
ref_b = "U" + str(href,16) + 



+ str(pin_a f 16) 
+ str(pin_b,16) 



if gfi test ref_a fails then 

if (gfi status ref_a) = "bad" then 

abort_test (ref_a) 
else 

if (gfi status ref_b) = "untested" then gfi test ref_b 
if (gfi status ref_b) = "bad" then 

abort_test (ref_b) 
end if 
end if 

gfi clear ! Only looking at Enable Lines, Clear Other Info, 
end if 
end function 



ram_ic[0] = 55 


\ 


ram_ic[l) 


= 


54 


ram_ic[2] = 53 


\ 


ram_ic[3] 


= 


52 


ram_ic[4] = 51 


\ 


ram_ic[5] 


= 


50 


ram_ic[6] = 49 


\ 


ram_ic[7] 


= 


48 


ram ic[8] = 41 


\ 


ram_ic[9] 


= 


40 


ram ic[10] = 39 


\ 


ram_ic[ll] 


= 


38 



ram_ic[12] 



37 \ ram_ic[13] 



ram_ic[14] = 35 \ ram ic[15] 



36 
34 



RAMs 


U55, 


U54 


RAMs 


U53, 


U52 


RAMs 


U51, 


U50 


RAMs 


U49, 


U48 


RAMs 


U41, 


U40 


RAMs 


U39, 


U38 


RAMs 


U37, 


U36 


RAMs 


U35, 


U34 



if contention_checked <> "yes" then 
contention_checked = "yes" 
podsetup 'report intr' "off" 
podsetup 'enable --ready' "on" 

print "\nl\nlTESTING BUS CONTENTION" 



Read from each device on the bus and record if each device reads correctly. 

Then check and see if all components are bad except one. If so then check 
that component's enable lines. 

Otherwise brute force check all enable lines on all components connected to 
the bus. 

! ROM0 and ROM1 

setspace ( getspace ("memory", "word") ) 

if (read addr $E002A) <> then bad_dev = bad_dev or 1 

if (read addr $F0022) <> then bad_dev = bad_dev or 2 

! Dynamic RAM 

write addr $1000, data $FFFF 

if (read addr $1000) <> $FFFF then bad_dev = bad_dev or 4 

write addr $1000, data 

if (read addr $1000) <> then bad_dev = bad_dev or 4 

! PIA registers 
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execute pia_init () 

if (read addr $4002) <> $FF then bad_dev = bad_dev or 8 

write addr $4002, data 

if (read addr $4002) <> then bad_dev = badjdev or 8 

! DUART registers 

execute rs232_init () 

if (read addr $200A) <> $11 then bad_dev = bad_dev or $10 

if {read addr $201A) <> $FF then badjdev = bad_dev or $10 

if (read addr $2012) <> $C then bad_dev - bad_dev or $10 



! Video Controller registers 

execute rs232_init () 

if (read addr 8) <> $FF then bad_dev = bad_dev or $20 

if (read addr $A) <> then bad_dev = bad_dev or $20 

If only one device is good, CLIP and check enable lines on that device. 



if bad_dev <> and bad_dev <> $3F then 
! CLIP and Check Enable lines on ROMs 
if bad_dev = $7E then 

if (data_bits and $FF) <> then 

testic(29, $20, $22) 
end if 
if (data_bits and $FF00) <> then 

testic(30, $20, $22) 
end if 



! Low data bits are bad 
! Check low byte ROM0. 

! High data bits are bad 
! Check high byte ROM0. 



else if bad_dev = $7D then 

if (data_bits and $FF) <> then 

testic(27, $20, $22) 
end if 
if (data_bits and $FF00) <> then 

testic(28, $20, $22) 
end if 



! Low data bits are bad 
! Check low byte ROM0. 

! High data bits are bad 
! Check high byte ROM0. 



else if bad_dev = $7B then 

testic (ram_ic[msb(data_bits) ] 
else if bad__dev = $77 then 

testic (31, 6, 6) 
else if badjdev = $2F then 

testic (11, $39, 9) 
else if bad_dev = $1F then 

testic (72, 2, 3) 
end if 
end if 



$15, 4) ! Check RAM. 

! Check PIA. 

! Check DUART. 

! Check Video Controller 



! BRUTE FORCE check enable lines of all devices on bus. 



if (datajDits and $FF) <> then 

testic (27, $20, $22) 

testic (29, $20, $22) 
end if 
if (data_bits and $FF00) <> then 

testic (28, $20, $22) 

testic (30, $20, $22) 
end if 

testic (ram_ic[msb(data_bits) ] , $15, 4) 
testic (31, 6, 6) 
testic (11, $39, 9) 
testic (72, 2, 3) 



! Low data bits are bad 
! Check low byte ROM0. 



! High data bits are bad 
I Check high byte ROM0„ 



! Check RAM. 

! Check PIA. 

! Check DUART. 

! Check Video Controller 
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testic (10, $11, 1) 
if bad_dev = $3F then 

if (data_bits and $FF) <> then 

if gfi test "U3-1" fails then abort_test ("U3-1") 
end if 
if (data_bits and $FF0O) <> then 

if gfi test "U23-1 M fails then abort_test ("U23-1") 
end if 
end if 



! Check Interrupt Buffer 



print "BUS CONTENTION TEST PASSES" 
end if 
end program 
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Index 



'masters, 4-5, 7-13 

ABORT_TEST program, 4-262 

Acoustic and visual characteristics, 4-380 

Active edge, 8-1 

Active interrupt lines, 4-8 See also interrupts 

ADDR_OUT stimulus program, 3-12, 4-20 

used in other chapters, 4-263, 4-283 
ADDRJDUT response file, 4-22 
Address buffers, 4-246 
Address Decode functional block, 4-273 

example, 4-276 

keystroke functional test, 4-277 

programmed functional test, 4-282 

stimulus programs and response files, 4-283 

summary page, 4-289 

testing and troubleshooting, 4-273 
Address decoder, 4-273 
Address latch, 4-273 
Address space, 4-14, 8-1 
Aliasing, 8-1 
arm command, 3-21 
Assert, 8-1 

assoc command, 3-19 
Asynchronous, 8-1 

Asynchronous level history, 2-7, 4-245, 7-8 
Asynchronous signals, 7-7 
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Automated test, 8-2 
Automated troubleshooting, 8-2 

Backtracing, 2-12, 6-1,8-2 

path, 7-14 
Baud-rate timing, 4-153 
Bidirectional lines, 3-10, 7-13 
Blinking cursors, 4-180 
Breakpoints, 4-8, 5-7 
Built-in fault condition exerciser, 7-23 
Built-in tests, 3-24, 4-3 

Microprocessor Bus, 4-7, 4-10 

RAM, 4-7, 4-59 

ROM, 4-7, 4-33 
Bus, 8-2 

arbitration, 4-248 

contention, 4-14, 4-33, 8-2 

controller, 4-351 

cycles, 2-1,4-7, 4-331 

emulation, 4-3 

exchange, 4-9, 4-248 

masters, 4-5, 7-13 
Bus Buffer functional block, 4-243 

example, 4-250 

keystroke functional test, 4-251 

programmed functional test, 4-262 

stimulus programs and response files, 4-263 

summary page, 4-272 

testing and troubleshooting, 4-243 

CAD, 8-2 

Calibration, 7-8 

CAS, See Column Address Strobe 

CAS__STIM stimulus program, 4-88, 4-92 

CAS_STIM response file, 4-94 

Character generator, 4-233 

Clearance, 4-3 

clip command, 3-19 

Clip module, 2-10, 3-19 

Clip module name, 3-19 

Clock and Reset functional block, 4-291 
example, 4-293 

keystroke functional test, 4-294 
programmed functional test, 4-300 
stimulus programs and response files, 4-301 
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Clock and Reset functional block, (continued) 

summary page, 4-312 

testing and troubleshooting, 4-291 
Clock signal, 7-5, 7-7 

Clocked level history, 2-7, 2-9, 2-10, 4-246 
Color look-up table, 4-177 
Column Address Strobe (CAS), 4-75 
Comment, 8-2 
Component, 8-2 
Component extraction tool, 4-3 
Connectors, 4-250 
Control lines, 4-247, 8-2 
Coprocessor cycles, 4-9 
Coupling fault, 4-61 

CRC signature, 2-10, 3-19, 4-245, 7-5, 8-2 
Crystal oscillator, 4-154, 4-291 
CTRL_OUT1 stimulus program, 3-16, 4-28 

used in other chapters, 4-263 
CTRL_OUT1 response file, 4-30 
CTRLJDUT2 stimulus program, 3-16, 4-266 
CTRL_OUT2 response file, 4-268 
CTRL_OUT3 stimulus program, 3-16, 4-269 

used in other chapters, 4-329 
CTRL_OUT3 response file, 4-271 
Cursor, 8-2 

Cursor timing output, 4-203 
Cycles 

bus, 2-1,4-7,4-331 

coprocessor, 4-8 

refresh, 4-9, 4-75, 4-79, 4-81 
Cyclic Redundancy Check (CRC), 2-6 

See also CRC signature 

Data bus, 8-3 

Data Compare Equal (DCE) condition, 2-10 

Data exchange protocol, 4-116 

Data tied to address, 4-38 

DATA__OUT stimulus program, 3-16, 4-17, 4-24 

used in other chapters, 4-263 
DATAJDUT response file, 4-26 
DECODE stimulus program, 4-283, 4-286 

used in other chapters, 4-46, 4-322 
DECODE response file, 4-288 
Delay line, 7-9 
Delay parameter, 4-61 
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Demo/Trainer UUT, 3-2, 4-1 , 4-10, 4-63, 6-3 
Device, 8-3 
Device name, 3-20 
Diagnostic messages 

bus test, 4-6 

RAM test, 4-62 

ROM test, 4-36 
Diagnostic program, 3-8, 6-1 
Diagnostic strategy, 6-3 
DIP, 8-3 

Direction control signals, 4-248 
Directory, 8-3 
Discrete 1/0,4-117 
DMA controllers, 4-9 
Downloading programs to the UUT, 5-8 
Drivability, 3-4, 8-3 
Drive capability, 2-9 
DTACK, 4-248, 4-331 
Dual UART (DUART), 4-155 
Dynamic coupling, 8-3 
Dynamic RAM, 4-59, 4-75 

adjusting sync timing for, 7-1 1 

multiplexed address, 4-75 

refresh, 4-9, 4-75, 4-79, 4-81 
Dynamic RAM Timing functional block, 4-75 

example, 4-79 

keystroke functional test, 4-83 

programmed functional test, 4-88 

stimulus programs and response files, 4-89 

summary page, 4-113 

testing and troubleshooting, 4-75 

Edge, 8-3 

Edge-sensitive inputs, 4-116 

Edit key, 7-18 

Editor, 7-17 

Electromechanical devices, 4-117 

Emulative testing, 2-2 

speed of emulation, 5-8 
enabled_line_timeoutiau\\ condition, 4-351 
Examples 

Address Decode, 4-276 

Bus Buffer, 4-250 

Clock and Reset, 4-293 

Interrupt Circuit, 4-316 
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Examples, (continued) 

Microprocessor Bus, 4-10 

Parallel I/O, 4-118 

Dynamic RAM Timing, 4-79 

RAM, 4-63 

Ready Circuit, 4-334 

ROM, 4-39 

Serial I/O, 4-155 

Video Control, 4-206 

Video Output, 4-180 

Video RAM, 4-233 
EXEC key, 4-381 

Exerciser, See fault condition exerciser 
External clock signal (sync), 2-10, 7-9 
External control lines, 2-10 
External I/O lines, 4-151 
External synchronization, 8-3 

Fault, 8-3 

fault command, 6-8, 6-9 

Fault condition, 6-8, 7-23, 8-3 

enabledJine_timeout, 4-351 

exerciser, 7-23, 8-4 

forcing-line, 4-350 

handler, 3-8, 5-8, 6-1 , 6-8, 8-4 

raising, 8-4 

ram_component, 4-66 

rom_address, 4-AA 

rom_comp, 4-44 
Fault coverage, 3-11, 5-3, 4-244 
Fault isolation, 2-11 
Feedback loop, 8-4 

breaking, 4-380 

Interrupt Circuit, 4-313 

Ready Circuit, 4-331 , 4-335 
Forcing lines, 4-379, 8-4 
Forcing signal conditions, 4-9 
Forcing-line fault condition, 4-350 
FRCJNT program, 4-160 
Freerun clock, 2-9 
Frequency, 2-7, 2-9, 4-246, 7-7 
Frequency min-max, 4-79, 4-292 
FREQUENCY stimulus program, 4-301, 4-310 

used in other chapters, 4-89, 4-176 
FREQUENCY response file, 4-31 1 
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Functional block, 3-1, 3-11, 3-16, 4-1 
Functional test, 1-5, 2-13, 3-8, 5-8, 8-4 

TEST_BUS, 4-14 

TEST_BUS2, 6-18, 6-17 

TEST_PIA, 4-124 

TEST_PIA2, 6-20, 6-17 

TEST_RAM , 4-66 

TEST_RAM2, 6-24, 6-17 

TEST_ROM, 4-44 

TEST_ROM2, 6-27, 6-17 

TEST_RS232, 4-160 

TEST_RS232B, 6-29, 6-17 

TEST_VIDEO, 4-186 

TEST_VIDE02, 6-31, 6-17 

TST_BUFFER, 4-262 

TST_CLOCK, 4-300 

TST_CONTEN, 4-15 

TST_DECODE, 4-282 

TSTJNTRPT, 4-322 

used in other chapters, 4-1 60 

TST_READY, 4-348 

TST_REFRSH, 4-88 

TST_VIDCTL, 4-216 

TSTVIDRAM, 4-238 

getoffset command, 4-77, 7-9 

GFI, See Guided Fault Isolation 

GFI hints, 2-13 

GFI key, 7-2 

GFI procedures, 1-5 

GFI summary, 8-4 

GFI troubleshooting, 2-12, 7-2 

gfi control command, 3-19 

gfi device command, 3-19 

gfi hint command, 3-8, 6-1 , 6-9 

gfi test command, 3-8, 3-24 

Glitches, 7-8 

Go/no-go test, 4-2, 5-1, 5-3, 6-1, 6-3, 8-4 

GO_NOG02 diagnostic program, 6-1 1 

Ground, 4-4 

Guided Fault Isolation (GFI), 1-5, 2-12, 3-12, 8-4 

Handler, See fault condition handler 
Hexadecimal, 8-5 
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HOLD line, 4-10 
HOLDA line, 4-10 

In-circuit component tests, 4-381 
In-circuit emulation, 2-2 
Initialization, 3-10, 3-17, 4-116 

Parallel I/O, 4-126 

RAM, 4-67 

Serial I/O, 4-162 

Video RAM, 4-238 
Interface pod, See pod 
Internal address bus, 4-246 
Internal operating modes, 4-116 
Internal sync, 2-10 

Interrupt acknowledge cycle, 3-16, 4-315 
Interrupt Circuit functional block, 4-313 

example, 4-316 

keystroke functional test, 4-316 

programmed functional test, 4-322 

stimulus programs and response files, 4-322 

summary page, 4-329 

testing and troubleshooting, 4-313 
INTERRUPT stimulus program, 4-322, 4-326 
INTERRUPT response file, 4-328 
Interrupt response file, 4-328 
Interrupts, 4-8 
Interrupt vector, 4-313 
I/O, 8-5 
I/O module, 2-4, 2-10, 3-17, 7-1, 7-11,8-5 

adjusting sync, 7-9 

breakpoints, 5-7 

calibration, 7-8 
I/O module adapter, 2-10 
I/O module name, 3-20 

Kernel, 4-5 

KEY_1 stimulus program, 4-126, 4-130 

KEY_1 response file, 4-132 

KEY_2 stimulus program, 4-126, 4-133 

KEY__2 response file, 4-135 

KEY_3 stimulus program, 4-126, 4-136 

KEY___3 response file, 4-138 

KEY_4 stimulus program, 4-126, 4-139 

KEY_4 response file, 4-141 

Keys, 4-117 
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Keystroke functional test 

Address Decode, 4-277 

Bus Buffer, 4-251 

Clock and Reset, 4-294 

Interrupt Circuit, 4-316 

Microprocessor Bus, 4-10 

Parallel I/O, 4-118 

Dynamic RAM Timing, 4-83 

RAM, 4-63 

Ready Circuit, 4-335 

ROM, 4-39 

Serial I/O, 4-156 

Video Control, 4-208 

Video Output, 4-181 

Video RAM, 4-233 
Keystroke mode, 1-5 
Known-good UUT, 3-10, 3-12, 7-4 

LEARN function, 7-4, 7-7 

Level 1 programming, 1-3 

Level 2 programming, 1-3 

Level 3 programming, 1-5 

Level 4 programming, 1-5 

Level history, 2-7, 2-9, 7-8, 8-5 

LEVELS stimulus program, 4-217, 4-226 

used in other chapters, 4-238 
LEVELS response file, 4-227 
Library, 8-5 
Line numbers, 3-20 
Local address bus, 4-246 
LOOP key, 7-23 
Loopback, 4-151 

Machine code, 5-8 
Mapped address bus, 4-246 
Marginal signals, 4-292 
Marginal signature, 7-5 
Mask, 8-5 
Masters, 4-5, 7-13 
Measurement device, 3-17 

calibration, 7-8 
Memory arbitration circuit, 4-205 
Microprocessor Bus functional block, 4-3 

example, 4-10 

keystroke functional test, 4-10 
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Microprocessor Bus functional block, (continued) 
programmed functional test, 4-14 
stimulus programs and response files, 4-17 
summary page, 4-31 
testing and troubleshooting, 4-5 

Microprocessor kernel, 4-5 

Milliohmmeter, 7-25 

Min-max, 4-79, 4-292 

Monitor, 8-5 

Msgskey, 7-18 

Multiple failures, 6-10 

Multiplexed address, 4-75 

Net list, 7-11 

Node, 8-5 

Node activity, 5-3 

Node characterization, 2-6 

Node list, 2-12, 7-11,8-5 

Noise, 4-292 

Normal mode, 2-9 

Open circuit, 7-24 

Operator, 8-5 

Operator's display, 8-6 

Operator's interface, 8-6 

Operator's keypad, 8-6 

Output loaded, 7-24 

Overdrive, 2-9, 2-10, 4-4, 4-206, 4-331, 4-381, 8-6 

Overlapped ramping operations, 4-244 

Parallel I/O functional block, 4-115 
example, 4-118 

keystroke functional test, 4-118 
programmed functional test, 4-124 
stimulus programs and response files, 4-126 
summary page, 4-149 
testing and troubleshooting, 4-115 

Part description, 7-12, 8-6 

Part library, 2-12, 7-11, 7-12, 8-6 

Partitioning the UUT, 3-1 

Pattern sensitive fault, 4-61 

Patterns, 2-1,3-19 

Peripheral devices, 4-313 

PIA_DATA stimulus program, 4-142 

PIAJDATA response file, 4-144 
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PIAJNIT initialization program, 4-126, 4-148 

PIAJ_EDS stimulus program, 4-126, 4-145 

PIA_LEDS response file, 4-146 

Pin coverage matrix, 7-21 

Pin numbers, 3-20 

Pin number parameters, 3-21 

Pod Address Sync, 2-9, 3-16, 4-77 

Pod Data Sync, 2-9, 3-16, 4-77 

Pod, 2-4, 2-9, 4-3, 5-8 

library, 8-6 

pod breakpoints, 4-8, 5-7 

synchronization, 8-6 
podsetup command, 4-5 
Power supply, 4-3 
Priority pin, 8-6 
Probe, 2-9, 3-17, 4-292, 7-1, 7-11,8-6 

adjusting sync, 7-9 

calibration, 7-8 

injecting faults with, 5-3 
Program library, 8-6 

Programmable Interface Adapter (PIA), 4-115 
Programmable Interval Timer (PIT), 4-115 
Programmed functional test 

Address Decode, 4-282 

Bus Buffer, 4-262 

Clock and Reset, 4-300 

Interrupt Circuit, 4-322 

Microprocessor Bus, 4-14 

Parallel I/O, 4-124 

Dynamic RAM Timing, 4-88 

RAM, 4-66 

Ready Circuit, 4-348 

ROM, 4-44 

Serial I/O, 4-160 

Video Control, 4-216 

Video Output, 4-186 

Video RAM, 4-238 
Programmer's interface, 1-5, 8-7 
Programmer's keyboard, 8-7 
Pull-up resistors, 4-4 

Quality characterization, 2-6 

Raise, See fault condition, raising 
RAM FAST test, 4-59 
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RAM FULL test, 4-59 
RAM QUICK test, 4-59 
RAM TEST key, 4-63 
RAM 

dynamic, 4-75 

sync timing, 7-11 

testing, 4-59 
ram_component fault condition, 4-66 
RAM_DATA stimulus program, 4-67, 4-70 

used in other chapters, 4-126 
RAM^DATA response file, 4-72 
RAM__FILL initialization program, 4-67, 4-73 
RAM functional block, 4-59 

example, 4-63 

keystroke functional test, 4-63 

programmed functional test, 4-66 

stimulus programs and response files, 4-67 

summary page, 4-74 

testing and troubleshooting, 4-59 
Ramp function, 4-244 
rampaddr command, 4-246 
rampdata command, 4-247 
RAMSELECT1 stimulus program, 4-89, 4-98 
RAMSELECT1 response file, 4-100 
RAMSELECT2 stimulus program, 4-89, 4-101 
RAMSELECT2 response file, 4-103 
RAM Timing, See Dynamic RAM Timing 
RAS, See Row Address Strobe 
RAS_STIM stimulus program, 4-88, 4-95 
RAS_STIM response file, 4-97 
RD_CSCD program, 4-160 
Read/Write strobe, 4-33 
readout command, 3-21 
Ready button, 3-17 
Ready Circuit functional block, 4-331 

example, 4-334 

keystroke functional test, 4-335 

programmed functional test, 4-348 

stimulus programs and response files, 4-349 

summary page, 4-378 

testing and troubleshooting, 4-331 
Ready signal, 4-248 

READY_1 stimulus program, 4-349, 4-354 
READY_1 response file, 4-357 
READY_2 stimulus program, 4-349, 4-358 
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READY_2 response file, 4-361 
READY_3 stimulus program, 4-349, 4-362 
READY_3 response file, 4-365 
READY_4 stimulus program, 4-349, 4-366 
READY_4 response file, 4-369 
READY__5 stimulus program, 4-349, 4-370 
READY_5 response file, 4-373 
READY_6 stimulus program, 4-349, 4-374 
READY_6 response file, 4-377 
Reference designator, 3-20, 7-1 1 , 8-7 
Reference designator list, 7-11 
Refresh, 4-9, 4-75, 4-79, 4-81, 4-75, 4-79, 4-81 
Refresh cycle, 4-9, 4-75, 4-79, 4-81 
REFSH_ADDR stimulus program, 4-89, 4-104 
REFSH_ADDR response file, 4-106 
REFSHJTIME stimulus program, 4-89, 4-107 
REFSHJIME response file, 4-109 
REFSH_U56 stimulus program, 4-89, 4-110 
REFSHJJ56 response file, 4-112 
Related input pin, 8-7 
Repair, 7-24 

Reset functional block, See Clock and Reset 
RESET_HIGH stimulus program, 4-301, 4-304 
RESET_HIGH response file, 4-306 
RESET_LOW stimulus program, 4-301, 4-307 

used in other chapters, 4-217, 4-283 
RESET_LOW response file, 4-309 
Response file, 3-12, 4-17, 7-4, 8-7 
rom_addre$s fault condition, 4-44 
romjcomp fault condition, 4-44 
ROM TEST key, 4-39 

ROM0_DATA stimulus program, 4-46, 4-50 
ROM0_DATA response file, 4-52 
ROM1_DATA stimulus program, 3-16, 4-46, 4-53 

used in other chapters, 4-263 
ROM1_DATA response file, 4-55 
ROM functional block, 4-33 

example, 4-39 

keystroke functional test, 4-39 

programmed functional test, 4-44 

stimulus programs and response files, 4-46 

summary page, 4-57 

testing and troubleshooting, 4-33 
Row Address Strobe (RAS), 4-75, 4-78 
RS-232 port, 4-154 
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RS232_DATA stimulus program, 4-163, 4-166 
RS232_DATA response file, 4-168 
RS232JNIT initialization program, 4-163, 4-175 
RS232J.VL stimulus program, 4-163, 4-169 
RS232_LVL response file, 4-171 
Rules for stimulus programs and response files, 4-17 
runuut command, 5-7 
RUN UUT mode, 2-9 
RUNUUT test, 8-7 

Serial interface adaptor, 4-151 
Serial I/O functional block, 4-151 

example, 4-155 

keystroke functional test, 4-156 

programmed functional test, 4-160 

stimulus programs and response files, 4-163 

summary page, 4-176 

testing and troubleshooting, 4-151 
setoff set command, 4-77, 7-9 
SETUP POD command, 4-5 
SIA , See serial interface adaptor 
Side (of I/O module), 2-10, 3-17 
Signature, See CRC signature 
SIP, 8-7 
Softkey, 8-7 
Start signal, 4-180 
State machine, 4-205, 4-331, 8-7 
Static electricity, 4-117 
Static logic levels, 4-4 
Static RAM, 4-59, 4-61, 4-75 
Status lines, 4-9 

Stimulus and measurement capabilities, 2-7 
Stimulus function, 7-23 
Stimulus program, 3-6, 3-16, 4-17, 7-2, 8-8 
Stimulus programs and response files 

Address Decode, 4-283 

Bus Buffer, 4-263 

Clock and Reset, 4-301 

Interrupt Circuit, 4-322 

Microprocessor Bus, 4-17 

Parallel I/O, 4-126 

Dynamic RAM Timing, 4-89 

RAM, 4-67 

Ready Circuit, 4-349 

ROM, 4-46 
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Stimulus programs and response files, (continued) 

Serial I/O, 4-163 

Video Control, 4-216 

Video Output, 4-187 

Video RAM, 4-238 
Stop signal, 4-180 
storepatt command, 3-19, 4-383 
String, 8-8 
Stuck bus lines, 4-5 
Stuck ceils, 4-59 
SUMMARY softkey, 7-17 
Summary of GFI coverage, 7-17 
Summary page 

Address Decode, 4-289 

Bus Buffer, 4-272 

Clock and Reset, 4-312 

Interrupt Circuit, 4-329 

Microprocessor Bus, 4-31 

Parallel I/O, 4-149 

Dynamic RAM Timing, 4-113 

RAM, 4-74 

Ready Circuit, 4-378 

ROM, 4-57 

Serial I/O, 4-176 

Video Control, 4-229 

Video Output, 4-202 

Video RAM, 4-242 
Switches, 4-117 
SYNC key, 4-8 
sync command, 4-8 
Sync timing, 7-9 
Synchronization mode, 2-9, 4-8, 7-8 

with ROM, 4-39 
Synchronous, 8-8 

Synchronous level history, 2-7, 2-9, 2-10, 4-246 
System address bus, 4-246 
System clock, 4-249 

Termination status, 8-8 

Test access, 4-3 

Test access socket, 4-10 

Test access switch, 4-10 

Test function, 7-23 

TEST_BUS functional test, 4-14 

TEST__BUS2 functional test, 6-17, 6-18 
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TEST_PIA functional test, 4-124 
TEST_PIA2 functional test, 6-17, 6-20 
TEST_RAM functional test, 4-66 
TEST_RAM2 functional test, 6-17, 6-24 
TEST_ROM functional test, 4-44 
TEST_ROM2 functional test, 6-17, 6-27 
TEST_RS232 functional test, 4-160 
TEST_RS232B functional test, 6-17, 6-29 
TEST_VIDEO functional test, 4-186 
TEST_VIDE02 functional test, 6-17, 6-32 
Testing and troubleshooting, 2-1, 3-1 

Address Decode, 4-273 

Bus Buffer, 4-243 

Clock and Reset, 4-291 

Interrupt Circuit, 4-313 

Microprocessor Bus, 4-5 

Parallel I/O, 4-115 

Dynamic RAM Timing, 4-75 

RAM, 4-59 

Ready Circuit, 4-331 

ROM, 4-33 

Serial I/O, 4-151 

Video Control, 4-205 

Video Output, 4-177 

Video RAM, 4-231 
Timeout, 8-8 

TL/1 programming language, 1-2, 1-6 
Toggle, 8-8 

togglecontrol command, 4-248 
Transition count, 2-7, 2-9, 2-107, 4-246, 7-4, 8-8 
Transition fault, 4-61 
Troubleshooting, 2-1, 3-1, 6-1, 7-1, 8-8 
TST_BUFFER functional test, 4-262 
TST_CLOCK functional test, 4-300 
TST_CONTEN functional test, 4-15 
TST_DECODE functional test, 4-282 
TSTJNTRPT functional test, 4-322 

used in other chapters, 4-160 
TST_READY functional test, 4-348 
TST.REFRSH functional test, 4-88 
TSTJ/IDCTL functional test, 4-216 
TST_VIDRAM functional test, 4-238 
TTL_LVL stimulus program, 4-163, 4-172 

used in other chapters, 4-322 
TTLJ_VL response file, 4-174 
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UART, See Universal Asynchronous Receiver-Transmitter 

Unguided Fault Isolation (UFI), 7-1 

Unit Under Test (UUT), 1-1,3-1,4-3,8-8 

Universal Asynchronous Receiver-Transmitter, 4-151 

Unprogrammed ROM, 4-38 

Unstable signature, 7-5 

Unused inputs, 4-4 

Use of pod, 2-9 

Userdisk, 8-8 

UUT, See Unit Under Test 

UUT clock, 4-4 

UUT directory, See summary page 

UUT go/no-go test, 3-8, 4-2, 5-1 , 5-3, 6-1 , 6-3, 6-9 

UUT partitioning, 3-1 

UUT voltage, 4-5 

Variable signature, 7-5 

Vertical scan rate, 4-203 

Vertical sync, 4-180 

Video cards, 4-180 

Video control, 4-203 

Video Control functional block, 4-203 

example, 4-206 

keystroke functional test, 4-208 

programmed functional test, 4-21 6 

stimulus programs and response files, 4-216 

summary page, 4-229 

testing and troubleshooting, 4-205 
Video display controller, 4-177 
VIDEOJDATA stimulus program, 4-216, 4-220 
VIDEO_DATA response file, 4-222 
VIDEO_FIL1 initialization program, 4-187, 4-200 

used in other chapters, 4-216, 4-238 
VIDEO_FIL2 initialization program, 4-187, 4-201 
VIDEO_FREQ stimulus program, 4-187, 4-190 

used in other chapters, 4-216 
VIDEO„FREQ response file, 4-190 
VIDEOJNIT initialization program, 4-187, 4-199 

used in other chapters, 4-217, 4-239 
Video Output functional block, 4-177 

example, 4-180 

keystroke functional test, 4-181 

programmed functional test, 4-186 

stimulus programs and response files, 4-187 
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Video Output functional block, (continued) 

summary page, 4-202 

testing and troubleshooting, 4-177 
VIDEO_OUT stimulus program, 4-187, 4-192 
VIDEO_OUT response file, 4-193 
Video RAM functional block, 4-231 

example, 4-233 

keystroke functional test, 4-233 

programmed functional test, 4-238 

stimulus programs and response files, 4-238 

summary page, 4-242 

testing and troubleshooting, 4-231 
VIDEO_RDY stimulus program, 4-217, 4-223 

used in other chapters, 4-238 
VIDEO_RDY response file, 4-224 
VIDEO_SCAN stimulus program, 4-187, 4-195 

used in other chapters, 4-216, 4-238 
VIDEO_SCAN response file, 4-196 
Visual or acoustic characteristics, 4-380 

Wait state, 4-331, 8-9 

Watchdog timer, 4-8, 4-379, 8-9 

Wildcard, 8-9 

Window, 8-9 

Wire list, 7-11 

WRITE BLOCK command, 5-8 

WRITE command, 5-8 

Write control signals, 4-248 

writepatt command, 3-20, 3-21, 4-381 
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